idnits 2.17.1 draft-ietf-pppext-l2tp-15.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? == It seems as if not all pages are separated by form feeds - found 0 form feeds but 73 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 14 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2661 has weird spacing: '...e local wai...' == Line 2662 has weird spacing: '...ndicate tunne...' == Line 2871 has weird spacing: '...e local wai...' == Line 3111 has weird spacing: '...hat are requi...' -- 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 (May 1999) is 9113 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 345, but not defined == Missing Reference: 'System' is mentioned on line 345, but not defined == Missing Reference: 'KPS' is mentioned on line 683, but not defined == Missing Reference: 'DSS1' is mentioned on line 1179, but not defined == Missing Reference: 'Remote' is mentioned on line 1830, but not defined == Missing Reference: 'RFC 2434' is mentioned on line 3197, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Missing Reference: 'PPTP' is mentioned on line 3283, but not defined == Unused Reference: 'RFC791' is defined on line 3213, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 3247, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 3267, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 3271, 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: 12 errors (**), 0 flaws (~~), 17 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 May 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 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 To learn the current status of any Internet-Draft, please check the 37 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 38 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 39 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 41 The distribution of this memo is unlimited. It is filed as and expires November 30, 1999. Please send 43 comments to the L2TP mailing list (l2tp@ipsec.org). 45 Copyright Notice 47 Copyright (C) The Internet Society (1999). All Rights Reserved. 48 Abstract 50 This document describes the Layer Two Tunneling Protocol (L2TP). RFC 51 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP 52 facilitates the tunneling of PPP packets across an intervening 53 network in a way that is as transparent as possible to both end-users 54 and applications. 56 Table of Contents 58 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.0 Topology . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.0 Protocol Overview . . . . . . . . . . . . . . . . . . . . 8 63 3.1 L2TP Header Format . . . . . . . . . . . . . . . . . . . . 9 64 3.2 Control Message Types . . . . . . . . . . . . . . . . . . 11 65 4.0 Control Message Attribute Value Pairs . . . . . . . . . . 12 66 4.1 AVP Format . . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.2 Hiding of AVP Values . . . . . . . . . . . . . . . . . . . 13 68 4.3 AVP Summary . . . . . . . . . . . . . . . . . . . . . . . 15 69 4.3.1 AVPs Applicable To All Control Messages . . . . . . . . . 16 70 4.3.2 Result and Error Codes . . . . . . . . . . . . . . . . . . 17 71 4.3.3 Control Connection Management AVPs . . . . . . . . . . . . 19 72 4.3.4 Call Management AVPs . . . . . . . . . . . . . . . . . . . 25 73 4.3.5 Proxy LCP and Authentication AVPs . . . . . . . . . . . . 32 74 4.3.6 Call Status AVPs . . . . . . . . . . . . . . . . . . . . . 37 75 5.0 Protocol Operation . . . . . . . . . . . . . . . . . . . . 38 76 5.1 Control Connection Establishment . . . . . . . . . . . . . 39 77 5.1.1 Tunnel Authentication . . . . . . . . . . . . . . . . . . 39 78 5.2 Session Establishment . . . . . . . . . . . . . . . . . . 40 79 5.2.1 Incoming Call Establishment . . . . . . . . . . . . . . . 40 80 5.2.2 Outgoing Call Establishment . . . . . . . . . . . . . . . 40 81 5.3 Forwarding PPP Frames . . . . . . . . . . . . . . . . . . 41 82 5.4 Using Sequence Numbers on the Data Channel . . . . . . . . 41 83 5.5 Keepalive (Hello) . . . . . . . . . . . . . . . . . . . . 42 84 5.6 Session Teardown . . . . . . . . . . . . . . . . . . . . . 43 85 5.7 Control Connection Teardown . . . . . . . . . . . . . . . 43 86 5.8 Reliable Delivery of Control Messages . . . . . . . . . . 43 87 6.0 Control Connection Protocol Specification . . . . . . . . 45 88 6.1 Start-Control-Connection-Request (SCCRQ) . . . . . . . . . 45 89 6.2 Start-Control-Connection-Reply (SCCRP) . . . . . . . . . . 46 90 6.3 Start-Control-Connection-Connected (SCCCN) . . . . . . . . 46 91 6.4 Stop-Control-Connection-Notification (StopCCN) . . . . . . 47 92 6.5 Hello (HELLO) . . . . . . . . . . . . . . . . . . . . . . 47 93 6.6 Incoming-Call-Request (ICRQ) . . . . . . . . . . . . . . . 48 94 6.7 Incoming-Call-Reply (ICRP) . . . . . . . . . . . . . . . . 48 95 6.8 Incoming-Call-Connected (ICCN) . . . . . . . . . . . . . . 49 96 6.9 Outgoing-Call-Request (ICRQ) . . . . . . . . . . . . . . . 49 97 6.10 Outgoing-Call-Reply (ICRP) . . . . . . . . . . . . . . . . 50 98 6.11 Outgoing-Call-Connected (OCCN) . . . . . . . . . . . . . . 50 99 6.12 Call-Disconnect-Notify (CDN) . . . . . . . . . . . . . . . 51 100 6.13 WAN-Error-Notify (WEN) . . . . . . . . . . . . . . . . . . 51 101 6.14 Set-Link-Info (SLI) . . . . . . . . . . . . . . . . . . . 52 102 7.0 Control Connection State Machines . . . . . . . . . . . . 52 103 7.1 Control Connection Protocol Operation . . . . . . . . . . 52 104 7.2 Control Connection States . . . . . . . . . . . . . . . . 52 105 7.2.1 Control Connection Establishment . . . . . . . . . . . . . 52 106 7.3 Timing considerations . . . . . . . . . . . . . . . . . . 55 107 7.4 Incoming Calls . . . . . . . . . . . . . . . . . . . . . . 55 108 7.4.1 LAC Incoming Call States . . . . . . . . . . . . . . . . . 56 109 7.4.2 LNS Incoming Call States . . . . . . . . . . . . . . . . . 58 110 7.5 Outgoing calls . . . . . . . . . . . . . . . . . . . . . . 59 111 7.5.1 LAC Outgoing Call States . . . . . . . . . . . . . . . . . 59 112 7.5.2 LNS Outgoing Call States . . . . . . . . . . . . . . . . . 61 113 7.6 Tunnel Disconnection . . . . . . . . . . . . . . . . . . . 62 114 8.0 L2TP Over Specific Media . . . . . . . . . . . . . . . . . 62 115 8.1 L2TP over UDP/IP . . . . . . . . . . . . . . . . . . . . . 63 116 8.2 IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 117 9.0 Security Considerations . . . . . . . . . . . . . . . . . . 64 118 9.1 Tunnel Endpoint Security . . . . . . . . . . . . . . . . . . 64 119 9.2 Packet Level Security . . . . . . . . . . . . . . . . . . . 65 120 9.3 End to End Security . . . . . . . . . . . . . . . . . . . . 65 121 9.4 L2TP and IPsec . . . . . . . . . . . . . . . . . . . . . . . 66 122 9.5 Proxy PPP Authentication . . . . . . . . . . . . . . . . . . 66 123 10.0 IANA Considerations . . . . . . . . . . . . . . . . . . . 66 124 10.1 AVP Attribute Type Values . . . . . . . . . . . . . . . . 66 125 10.2 Message AVP Values . . . . . . . . . . . . . . . . . . . . 67 126 10.3 Result Code AVP Values . . . . . . . . . . . . . . . . . . 67 127 10.4 Framing Capabilities & Bearer Capabilities . . . . . . . . 67 128 10.5 Proxy Authen Type AVP Values . . . . . . . . . . . . . . . 67 129 10.6 AVP Header Bits . . . . . . . . . . . . . . . . . . . . . 67 130 11.0 References . . . . . . . . . . . . . . . . . . . . . . . . 68 131 12.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 69 132 13.0 Author's Addresses . . . . . . . . . . . . . . . . . . . . 70 133 Appendix A: Control Channel Slow Start and Congestion 134 Avoidance . . . . . . . . . . . . . . . . . . . . . 70 135 Appendix B: Control Message Examples . . . . . . . . . . . . . . 71 136 Appendix C: Intellectual Property Notice . . . . . . . . . . . . 73 138 1.0 Introduction 140 PPP [RFC1661] defines an encapsulation mechanism for transporting 141 multiprotocol packets across layer 2 (L2) point-to-point links. 142 Typically, a user obtains a L2 connection to a Network Access Server 143 (NAS) using one of a number of techniques (e.g., dialup POTS, ISDN, 144 ADSL, etc.) and then runs PPP over that connection. In such a 145 configuration, the L2 termination point and PPP session endpoint 146 reside on the same physical device (i.e., the NAS). 148 L2TP extends the PPP model by allowing the L2 and PPP endpoints to 149 reside on different devices interconnected by a packet-switched 150 network. With L2TP, a user has an L2 connection to an access 151 concentrator (e.g., modem bank, ADSL DSLAM, etc.), and the 152 concentrator then tunnels individual PPP frames to the NAS. This 153 allows the actual processing of PPP packets to be divorced from the 154 termination of the L2 circuit. 156 One obvious benefit of such a separation is that instead of requiring 157 the L2 connection terminate at the NAS (which may require a long- 158 distance toll charge), the connection may terminate at a (local) 159 circuit concentrator, which then extends the logical PPP session over 160 a shared infrastructure such as frame relay circuit or the Internet. 161 From the user's perspective, there is no functional difference 162 between having the L2 circuit terminate in a NAS directly or using 163 L2TP. 165 L2TP may also solve the multilink hunt-group splitting problem. 166 Multilink PPP [RFC1990] requires that all channels composing a 167 multilink bundle be grouped at a single Network Access Server (NAS). 168 Due to its ability to project a PPP session to a location other than 169 the point at which it was physically received, L2TP can be used to 170 make all channels terminate at a single NAS. This allows multilink 171 operation even when the calls are spread across distinct physical 172 NASs. 174 This document defines the necessary control protocol for on-demand 175 creation of tunnels between two nodes and the accompanying 176 encapsulation for multiplexing multiple, tunneled PPP sessions. 178 1.1 Specification of Requirements 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 1.2 Terminology 186 Analog Channel 188 A circuit-switched communication path which is intended to carry 189 3.1 kHz audio in each direction. 191 Attribute Value Pair (AVP) 193 The variable length concatenation of a unique Attribute 194 (represented by an integer) and a Value containing the actual 195 value identified by the attribute. Multiple AVPs make up Control 196 Messages which are used in the establishment, maintenance, and 197 teardown of tunnels. 199 Call 201 A connection (or attempted connection) between a Remote System and 202 LAC. For example, a telephone call through the PSTN. A Call 203 (Incoming or Outgoing) which is successfully established between a 204 Remote System and LAC results in a corresponding L2TP Session 205 within a previously established Tunnel between the LAC and LNS. 206 (See also: Session, Incoming Call, Outgoing Call). 208 Called Number 210 An indication to the receiver of a call as to what telephone 211 number the caller used to reach it. 213 Calling Number 215 An indication to the receiver of a call as to the telephone number 216 of the caller. 218 CHAP 220 Challenge Handshake Authentication Protocol [RFC1994], a PPP 221 cryptographic challenge/response authentication protocol in which 222 the cleartext password is not passed over the line. 224 Control Connection 226 A control connection operates in-band over a tunnel to control the 227 establishment, release, and maintenance of sessions and of the 228 tunnel itself. 230 Control Messages 232 Control messages are exchanged between LAC and LNS pairs, 233 operating in-band within the tunnel protocol. Control messages 234 govern aspects of the tunnel and sessions within the tunnel. 236 Digital Channel 238 A circuit-switched communication path which is intended to carry 239 digital information in each direction. 241 DSLAM 243 Digital Subscriber Line (DSL) Access Module. A network device used 244 in the deployment of DSL service. This is typically a concentrator 245 of individual DSL lines located in a central office (CO) or local 246 exchange. 248 Incoming Call 250 A Call received at an LAC to be tunneled to an LNS (see Call, 251 Outgoing Call). 253 L2TP Access Concentrator (LAC) 255 A node that acts as one side of an L2TP tunnel endpoint and is a 256 peer to the L2TP Network Server (LNS). The LAC sits between an 257 LNS and a remote system and forwards packets to and from each. 258 Packets sent from the LAC to the LNS requires tunneling with the 259 L2TP protocol as defined in this document. The connection from 260 the LAC to the remote system is either local (see: Client LAC) or 261 a PPP link. 263 L2TP Network Server (LNS) 265 A node that acts as one side of an L2TP tunnel endpoint and is a 266 peer to the L2TP Access Concentrator (LAC). The LNS is the 267 logical termination point of a PPP session that is being tunneled 268 from the remote system by the LAC. 270 Management Domain (MD) 272 A network or networks under the control of a single 273 administration, policy or system. For example, an LNS's Management 274 Domain might be the corporate network it serves. An LAC's 275 Management Domain might be the Internet Service Provider that owns 276 and manages it. 278 Network Access Server (NAS) 280 A device providing local network access to users across a remote 281 access network such as the PSTN. An NAS may also serve as an LAC, 282 LNS or both. 284 Outgoing Call 286 A Call placed by an LAC on behalf of an LNS (see Call, Incoming 287 Call). 289 Peer 291 When used in context with L2TP, peer refers to either the LAC or 292 LNS. An LAC's Peer is an LNS and vice versa. When used in context 293 with PPP, a peer is either side of the PPP connection. 295 POTS 297 Plain Old Telephone Service. 299 Remote System 301 An end-system or router attached to a remote access network (i.e. 302 a PSTN), which is either the initiator or recipient of a call. 303 Also referred to as a dial-up or virtual dial-up client. 305 Session 307 L2TP is connection-oriented. The LNS and LAC maintain state for 308 each Call that is initiated or answered by an LAC. An L2TP Session 309 is created between the LAC and LNS when an end-to-end PPP 310 connection is established between a Remote System and the LNS. 311 Datagrams related to the PPP connection are sent over the Tunnel 312 between the LAC and LNS. There is a one to one relationship 313 between established L2TP Sessions and their associated Calls. (See 314 also: Call). 316 Tunnel 318 A Tunnel exists between a LAC-LNS pair. The Tunnel consists of a 319 Control Connection and zero or more L2TP Sessions. The Tunnel 320 carries encapsulated PPP datagrams and Control Messages between 321 the LAC and the LNS. 323 Zero-Length Body (ZLB) Message 325 A control packet with only an L2TP header. ZLB messages are used 326 for explicitly acknowledging packets on the reliable control 327 channel. 329 2.0 Topology 331 The following diagram depicts a typical L2TP scenario. The goal is to 332 tunnel PPP frames between the Remote System or LAC Client and an LNS 333 located at a Home LAN. 335 [Home LAN] 336 [LAC Client]----------+ | 337 ____|_____ +--[Host] 338 | | | 339 [LAC]---------| Internet |-----[LNS]-----+ 340 | |__________| | 341 _____|_____ : 342 | | 343 | PSTN | 344 [Remote]--| Cloud | 345 [System] | | [Home LAN] 346 |___________| | 347 | ______________ +---[Host] 348 | | | | 349 [LAC]-------| Frame Relay |---[LNS]-----+ 350 | or ATM Cloud | | 351 |______________| : 353 The Remote System initiates a PPP connection across the PSTN Cloud to 354 an LAC. The LAC then tunnels the PPP connection across the Internet, 355 Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN is 356 obtained. The Remote System is provided addresses from the HOME LAN 357 via PPP NCP negotiation. Authentication, Authorization and Accounting 358 may be provided by the Home LAN's Management Domain as if the user 359 were connected to a Network Access Server directly. 361 A LAC Client (a Host which runs L2TP natively) may also participate 362 in tunneling to the Home LAN without use of a separate LAC. In this 363 case, the Host containing the LAC Client software already has a 364 connection to the public Internet. A "virtual" PPP connection is then 365 created and the local L2TP LAC Client software creates a tunnel to 366 the LNS. As in the above case, Addressing, Authentication, 367 Authorization and Accounting will be provided by the Home LAN's 368 Management Domain. 370 3.0 Protocol Overview 372 L2TP utilizes two types of messages, control messages and data 373 messages. Control messages are used in the establishment, maintenance 374 and clearing of tunnels and calls. Data messages are used to 375 encapsulate PPP frames being carried over the tunnel. Control 376 messages utilize a reliable Control Channel within L2TP to guarantee 377 delivery (see section 5.1 for details). Data messages are not 378 retransmitted when packet loss occurs. 380 +-------------------+ 381 | PPP Frames | 382 +-------------------+ +-----------------------+ 383 | L2TP Data Messages| | L2TP Control Messages | 384 +-------------------+ +-----------------------+ 385 | L2TP Data Channel | | L2TP Control Channel | 386 | (unreliable) | | (reliable) | 387 +------------------------------------------------+ 388 | Packet Transport (UDP, FR, ATM, etc.) | 389 +------------------------------------------------+ 391 Figure 3.0 L2TP Protocol Structure 393 Figure 3.0 depicts the relationship of PPP frames and Control 394 Messages over the L2TP Control and Data Channels. PPP Frames are 395 passed over an unreliable Data Channel encapsulated first by an L2TP 396 header and then a Packet Transport such as UDP, Frame Relay, ATM, 397 etc. Control messages are sent over a reliable L2TP Control Channel 398 which transmits packets in-band over the same Packet Transport. 400 Sequence numbers are required to be present in all control messages 401 and are used to provide reliable delivery on the Control Channel. 402 Data Messages may use sequence numbers to reorder packets and detect 403 lost packets. 405 All values are placed into their respective fields and sent in 406 network order (high order octets first). 408 3.1 L2TP Header Format 410 L2TP packets for the control channel and data channel share a common 411 header format. In each case where a field is optional, its space does 412 not exist in the message if the field is marked not present. This 413 header is formatted: 415 0 1 2 3 416 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Tunnel ID | Session ID | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Ns (opt) | Nr (opt) | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Offset Size (opt) | Offset pad... (opt) 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Figure 3.1 L2TP Message Header 428 The Type (T) bit indicates the type of message. It is set to 0 for a 429 data message and 1 for a control message. 431 If the Length (L) bit is 1, the Length field is present. This bit 432 MUST be set to 1 for control messages. 434 The x bits are reserved for future extensions. All reserved bits MUST 435 be set to 0 on outgoing messages and ignored on incoming messages. 437 If the Sequence (S) bit is set to 1 the Ns and Nr fields are present. 438 The S bit MUST be set to 1 for control messages. 440 If the Offset (O) bit is 1, the Offset Size field is present. The O 441 bit MUST be set to 0 (zero) for control messages. 443 If the Priority (P) bit is 1, this data message should receive 444 preferential treatment in its local queuing and transmission. LCP 445 echo requests used as a keepalive for the link, for instance, should 446 generally be sent with this bit set to 1. Without it, a temporary 447 interval of local congestion could result in interference with 448 keepalive messages and unnecessary loss of the link. This feature is 449 only for use with data messages. The P bit MUST be set to 0 for all 450 control messages. 452 Ver MUST be 2, indicating the version of the L2TP data message header 453 described in this document. The value 1 is reserved to permit 454 detection of L2F [RFC2341] packets should they arrive intermixed with 455 L2TP packets. Packets received with an unknown Ver field MUST be 456 discarded. 458 The Length field indicates the total length of the message in octets. 460 Tunnel ID indicates the identifier for the control connection. L2TP 461 tunnels are named by identifiers that have local significance only. 462 That is, the same tunnel will be given different Tunnel IDs by each 463 end of the tunnel. Tunnel ID in each message is that of the intended 464 recipient, not the sender. Tunnel IDs are selected and exchanged as 465 Assigned Tunnel ID AVPs during the creation of a tunnel. 467 Session ID indicates the identifier for a session within a tunnel. 468 L2TP sessions are named by identifiers that have local significance 469 only. That is, the same session will be given different Session IDs 470 by each end of the session. Session ID in each message is that of the 471 intended recipient, not the sender. Session IDs are selected and 472 exchanged as Assigned Session ID AVPs during the creation of a 473 session. 475 Ns indicates the sequence number for this data or control message, 476 beginning at zero and incrementing by one (modulo 2**16) for each 477 message sent. See Section 5.8 and 5.4 for more information on using 478 this field. 480 Nr indicates the sequence number expected in the next control message 481 to be received. Thus, Nr is set to the Ns of the last in-order 482 message received plus one (modulo 2**16). In data messages, Nr is 483 reserved and, if present (as indicated by the S-bit), MUST be ignored 484 upon receipt. See section 5.8 for more information on using this 485 field in control messages. 487 The Offset Size field, if present, specifies the number of octets 488 past the L2TP header at which the payload data is expected to start. 489 Actual data within the offset padding is undefined. If the offset 490 field is present, the L2TP header ends after the last octet of the 491 offset padding. 493 3.2 Control Message Types 495 The Message Type AVP (see section 4.3.1) defines the specific type of 496 control message being sent. Recall from section 3.1 that this is only 497 for control messages, that is, messages with the T-bit set to 1. 499 This document defines the following control message types (see 500 Section 6.1 through 6.14 for details on the construction and use of 501 each message): 503 Control Connection Management 505 0 (reserved) 507 1 (SCCRQ) Start-Control-Connection-Request 508 2 (SCCRP) Start-Control-Connection-Reply 509 3 (SCCCN) Start-Control-Connection-Connected 510 4 (StopCCN) Stop-Control-Connection-Notification 511 5 (reserved) 512 6 (HELLO) Hello 514 Call Management 516 7 (OCRQ) Outgoing-Call-Request 517 8 (OCRP) Outgoing-Call-Reply 518 9 (OCCN) Outgoing-Call-Connected 519 10 (ICRQ) Incoming-Call-Request 520 11 (ICRP) Incoming-Call-Reply 521 12 (ICCN) Incoming-Call-Connected 522 13 (reserved) 523 14 (CDN) Call-Disconnect-Notify 525 Error Reporting 527 15 (WEN) WAN-Error-Notify 529 PPP Session Control 531 16 (SLI) Set-Link-Info 533 4.0 Control Message Attribute Value Pairs 535 To maximize extensibility while still permitting interoperability, a 536 uniform method for encoding message types and bodies is used 537 throughout L2TP. This encoding will be termed AVP (Attribute-Value 538 Pair) in the remainder of this document. 540 4.1 AVP Format 542 Each AVP is encoded as: 544 0 1 2 3 545 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 |M|H| rsvd | Length | Vendor ID | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Attribute Type | Attribute Value... 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 [until Length is reached]... | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 The first six bits are a bit mask, describing the general attributes 555 of the AVP. 557 Two bits are defined in this document, the remaining are reserved for 558 future extensions. Reserved bits MUST be set to 0. An AVP received 559 with a reserved bit set to 1 MUST be treated as an unrecognized AVP. 561 Mandatory (M) bit: Controls the behavior required of an 562 implementation which receives an AVP which it does not recognize. If 563 the M bit is set on an unrecognized AVP within a message associated 564 with a particular session, the session associated with this message 565 MUST be terminated. If the M bit is set on an unrecognized AVP within 566 a message associated with the overall tunnel, the entire tunnel (and 567 all sessions within) MUST be terminated. If the M bit is not set, an 568 unrecognized AVP MUST be ignored. The control message must then 569 continue to be processed as if the AVP had not been present. 571 Hidden (H) bit: Identifies the hiding of data in the Attribute Value 572 field of an AVP. This capability can be used to avoid the passing of 573 sensitive data, such as user passwords, as cleartext in an AVP. 574 Section 4.2 describes the procedure for performing AVP hiding. 576 Length: Encodes the number of octets (including the Overall Length 577 and bitmask fields) contained in this AVP. The Length may be 578 calculated as 6 + the length of the Attribute Value field in octets. 579 The field itself is 10 bits, permitting a maximum of 1023 octets of 580 data in a single AVP. The minimum Length of an AVP is 6. If the 581 length is 6, then the Attribute Value field is absent. 583 Vendor ID: The IANA assigned "SMI Network Management Private 584 Enterprise Codes" [RFC1700] value. The value 0, corresponding to 585 IETF adopted attribute values, is used for all AVPs defined within 586 this document. Any vendor wishing to implement their own L2TP 587 extensions can use their own Vendor ID along with private Attribute 588 values, guaranteeing that they will not collide with any other 589 vendor's extensions, nor with future IETF extensions. Note that there 590 are 16 bits allocated for the Vendor ID, thus limiting this feature 591 to the first 65,535 enterprises. 593 Attribute Type: A 2 octet value with a unique interpretation across 594 all AVPs defined under a given Vendor ID. 596 Attribute Value: This is the actual value as indicated by the Vendor 597 ID and Attribute Type. It follows immediately after the Attribute 598 Type field, and runs for the remaining octets indicated in the Length 599 (i.e., Length minus 6 octets of header). This field is absent if the 600 Length is 6. 602 4.2 Hiding of AVP Attribute Values 604 The H bit in the header of each AVP provides a mechanism to indicate 605 to the receiving peer whether the contents of the AVP are hidden or 606 present in cleartext. This feature can be used to hide sensitive 607 control message data such as user passwords or user IDs. 609 The H bit MUST only be set if a shared secret exists between the LAC 610 and LNS. The shared secret is the same secret that is used for tunnel 611 authentication (see Section 5.1.1). If the H bit is set in any 612 AVP(s) in a given control message, a Random Vector AVP must also be 613 present in the message and MUST precede the first AVP having an H bit 614 of 1. 616 Hiding an AVP value is done in several steps. The first step is to 617 take the length and value fields of the original (cleartext) AVP and 618 encode them into a Hidden AVP Subformat as follows: 620 0 1 2 3 621 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Length of Original Value | Original Attribute Value ... 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 ... | Padding ... 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Length of Original Attribute Value: This is length of the Original 629 Attribute Value to be obscured in octets. This is necessary to 630 determine the original length of the Attribute Value which is lost 631 when the additional Padding is added. 633 Original Attribute Value: Attribute Value that is to be obscured. 635 Padding: Random additional octets used to obscure length of the 636 Attribute Value that is being hidden. 638 To mask the size of the data being hidden, the resulting subformat 639 MAY be padded as shown above. Padding does NOT alter the value placed 640 in the Length of Original Attribute Value field, but does alter the 641 length of the resultant AVP that is being created. For example, If an 642 Attribute Value to be hidden is 4 octets in length, the unhidden AVP 643 length would be 10 octets (6 + Attribute Value length). After hiding, 644 the length of the AVP will become 6 + Attribute Value length + size 645 of the Length of Original Attribute Value field + Padding. Thus, if 646 Padding is 12 octects, the AVP length will be 6 + 4 + 2 + 12 = 24 647 octets. 649 Next, An MD5 hash is performed on the concatenation of: 651 + the 2 octet Attribute number of the AVP 652 + the shared secret 653 + an arbitrary length random vector 655 The value of the random vector used in this hash is passed in the 656 value field of a Random Vector AVP. This Random Vector AVP must be 657 placed in the message by the sender before any hidden AVPs. The same 658 random vector may be used for more than one hidden AVP in the same 659 message. If a different random vector is used for the hiding of 660 subsequent AVPs then a new Random Vector AVP must be placed in the 661 command message before the first AVP to which it applies. 663 The MD5 hash value is then XORed with the first 16 octet (or less) 664 segment of the Hidden AVP Subformat and placed in the Attribute Value 665 field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 666 octets, the Subformat is transformed as if the Attribute Value field 667 had been padded to 16 octets before the XOR, but only the actual 668 octets present in the Subformat are modified, and the length of the 669 AVP is not altered. 671 If the Subformat is longer than 16 octets, a second one-way MD5 hash 672 is calculated over a stream of octets consisting of the shared secret 673 followed by the result of the first XOR. That hash is XORed with the 674 second 16 octet (or less) segment of the Subformat and placed in the 675 corresponding octets of the Value field of the Hidden AVP. 677 If necessary, this operation is repeated, with the shared secret used 678 along with each XOR result to generate the next hash to XOR the next 679 segment of the value with. 681 The hiding method was adapted from RFC 2138 [RFC2138] which was taken 682 from from the "Mixing in the Plaintext" section in the book "Network 683 Security" by Kaufman, Perlman and Speciner [KPS]. A detailed 684 explanation of the method follows: 686 Call the shared secret S, the Random Vector RV, and the Attribute 687 Value AV. Break the value field into 16-octet chunks p1, p2, etc. 688 with the last one padded at the end with random data to a 16-octet 689 boundary. Call the ciphertext blocks c(1), c(2), etc. We will also 690 define intermediate values b1, b2, etc. 692 b1 = MD5(AV + S + RV) c(1) = p1 xor b1 693 b2 = MD5(S + c(1)) c(2) = p2 xor b2 694 . . 695 . . 696 . . 697 bi = MD5(S + c(i-1)) c(i) = pi xor bi 699 The String will contain c(1)+c(2)+...+c(i) where + denotes 700 concatenation. 702 On receipt, the random vector is taken from the last Random Vector 703 AVP encountered in the message prior to the AVP to be unhidden. The 704 above process is then reversed to yield the original value. 706 4.3 AVP Summary 708 The following sections contain a list of all L2TP AVPs defined in 709 this document. 711 Following the name of the AVP is a list indicating the message types 712 that utilize each AVP. After each AVP title follows a short 713 description of the purpose of the AVP, a detail (including a graphic) 714 of the format for the Attribute Value, and any additional information 715 needed for proper use of the avp. 717 4.3.1 AVPs Applicable To All Control Messages 719 Message Type (All Messages) 721 The Message Type AVP, Attribute Type 0, identifies the control 722 message herein and defines the context in which the exact meaning 723 of the following AVPs will be determined. 725 The Attribute Value field for this AVP has the following format: 727 0 1 728 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Message Type | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 The Message Type is a 2 octet unsigned integer. 735 The Message Type AVP MUST be the first AVP in a message, 736 immediately following the control message header (defined in 737 section 3.1). See Section 3.2 for the list of defined control 738 message types and their identifiers. 740 The Mandatory (M) bit within the Message Type AVP has special 741 meaning. Rather than an indication as to whether the AVP itself 742 should be ignored if not recognized, it is an indication as to 743 whether the control message itself should be ignored. Thus, if the 744 M-bit is set within the Message Type AVP and the Message Type is 745 unknown to the implementation, the tunnel MUST be cleared. If the 746 M-bit is not set, then the implementation may ignore an unknown 747 message type. The M-bit MUST be set to 1 for all message types 748 defined in this document. This AVP may not be hidden (the H-bit 749 MUST be 0). The Length of this AVP is 8. 751 Random Vector (All Messages) 753 The Random Vector AVP, Attribute Type 36, is used to enable the 754 hiding of the Attribute Value of arbitrary AVPs. 756 The Attribute Value field for this AVP has the following format: 758 0 1 2 3 759 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Random Octet String ... 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 The Random Octet String may be of arbitrary length, although a 765 random vector of at least 16 octets is recommended. The string 766 contains the random vector for use in computing the MD5 hash to 767 retrieve or hide the Attribute Value of a hidden AVP (see Section 768 4.2). 770 More than one Random Vector AVP may appear in a message, in which 771 case a hidden AVP uses the Random Vector AVP most closely 772 preceeding it. This AVP MUST precede the first AVP with the H bit 773 set. 775 The M-bit for this AVP MUST be set to 1. This AVP MUST NOT be 776 hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the 777 length of the Random Octet String. 779 4.3.2 Result and Error Codes 781 Result Code (CDN, StopCCN) 783 The Result Code AVP, Attribute Type 1, indicates the reason for 784 terminating the control channel or session. 786 The Attribute Value field for this AVP has the following format: 788 0 1 2 3 789 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Result Code | Error Code (opt) | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Error Message (opt) ... 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 The Result Code is a 2 octet unsigned integer. The optional Error 797 Code is a 2 octet unsigned integer. An optional Error Message can 798 follow the Error Code field. Presence of the Error Code and 799 Message are indicated by the AVP Length field. The Error Message 800 contains an arbitrary string providing further (human readable) 801 text associated with the condition. Human readable text in all 802 error messages MUST be provided in the UTF-8 charset using the 803 Default Language [RFC2277]. 805 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 806 this AVP MUST be set to 1. The Length is 8 if there is no Error 807 Code or Message, 10 if there is an Error Code and no Error Message 808 or 10 + the length of the Error Message if there is an Error Code 809 and Message. 811 Defined Result Code values for the StopCCN message are: 813 0 - Reserved 814 1 - General request to clear control connection 815 2 - General error--Error Code indicates the problem 816 3 - Control channel already exists 817 4 - Requester is not authorized to establish a control channel 818 5 - The protocol version of the requester is not supported 819 Error Code indicates highest version supported 820 6 - Requester is being shut down 821 7 - Finite State Machine error 823 Defined Result Code values for the CDN message are: 825 0 - Reserved 826 1 - Call disconnected due to loss of carrier 827 2 - Call disconnected for the reason indicated 828 in error code 829 3 - Call disconnected for administrative reasons 830 4 - Call failed due to lack of appropriate facilities being 831 available (temporary condition) 832 5 - Call failed due to lack of appropriate facilities being 833 available (permanent condition) 834 6 - Invalid destination 835 7 - Call failed due to no carrier detected 836 8 - Call failed due to detection of a busy signal 837 9 - Call failed due to lack of a dial tone 838 10 - Call was not established within time allotted by LAC 839 11 - Call was connected but no appropriate framing was detected 841 The Error Codes defined below pertain to types of errors that are 842 not specific to any particular L2TP request, but rather to 843 protocol or message format errors. If an L2TP reply indicates in 844 its Result Code that a general error occurred, the General Error 845 value should be examined to determine what the error was. The 846 currently defined General Error codes and their meanings are: 848 0 - No general error 849 1 - No control connection exists yet for this LAC-LNS pair 850 2 - Length is wrong 851 3 - One of the field values was out of range or 852 reserved field was non-zero 853 4 - Insufficient resources to handle this operation now 854 5 - The Session ID is invalid in this context 855 6 - A generic vendor-specific error occurred in the LAC 856 7 - Try another. If LAC is aware of other possible LNS 857 destinations, it should try one of them. This can be 858 used to guide an LAC based on LNS policy, for instance, 859 the existence of multilink PPP bundles. 861 When a General Error Code of 6 is used, additional information 862 about the error SHOULD be included in the Error Message field. 864 4.3.3 Control Connection Management AVPs 866 Protocol Version (SCCRP, SCCRQ) 868 The Protocol Version AVP, Attribute Type 2, indicates the L2TP 869 protocol version of the sender. 871 The Attribute Value field for this AVP has the following format: 873 0 1 874 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Ver | Rev | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 The Ver field is a 1 octet unsigned integer containing the value 880 1. Rev field is a 1 octet unsigned integer containing 0. This 881 pertains to L2TP protocol version 1, revision 0. Note this is not 882 the same version number that is included in the header of each 883 message. 885 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 886 this AVP MUST be set to 1. The Length of this AVP is 8. 888 Framing Capabilities (SCCRP, SCCRQ) 890 The Framing Capabilities AVP, Attribute Type 3, provides the peer 891 with an indication of the types of framing that will be accepted 892 or requested by the sender. 894 The Attribute Value field for this AVP has the following format: 896 0 1 2 3 897 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Reserved for future framing type definitions |A|S| 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 The Attribute Value field is a 32-bit mask, with two bits defined. 903 If bit A is set, asynchronous framing is supported. If bit S is 904 set, synchronous framing is supported. 906 A peer MUST NOT request an incoming or outgoing call with a 907 Framing Type AVP specifying a value not advertised in the Framing 908 Capabilities AVP it received during control connection 909 establishment. Attempts to do so will result in the call being 910 rejected. 912 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 913 this AVP MUST be set to 1. The Length (before hiding) is 10. 915 Bearer Capabilities (SCCRP, SCCRQ) 917 The Bearer Capabilities AVP, Attribute Type 4, provides the peer 918 with an indication of the bearer device types supported by the 919 hardware interfaces of the sender for outgoing calls. 921 The Attribute Value field for this AVP has the following format: 923 0 1 2 3 924 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Reserved for future bearer type definitions |A|D| 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 This is a 32-bit mask, with two bits defined. If bit A is set, 930 analog access is supported. If bit D is set, digital access is 931 supported. 933 An LNS should not request an outgoing call specifying a value in 934 the Bearer Type AVP for a device type not advertised in the Bearer 935 Capabilities AVP it received from the LAC during control 936 connection establishment. Attempts to do so will result in the 937 call being rejected. 939 This AVP MUST be present if the sender can place outgoing calls 940 when requested. 942 Note that an LNS that cannot act as an LAC as well will not 943 support hardware devices for handling incoming and outgoing calls 944 and should therefore set the A and D bits of this AVP to 0, or 945 should not send the AVP at all. An LNS that can also act as an LAC 946 and place outgoing calls should set A or D as appropriate. 947 Presence of this message is not a guarantee that a given outgoing 948 call will be placed by the sender if requested, just that the 949 physical capability exists. 951 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 952 this AVP MUST be set to 1. The Length (before hiding) is 10. 954 Tie Breaker (SCCRQ) 956 The Tie Breaker AVP, Attribute Type 5, indicates that the sender 957 wishes a single tunnel to exist between the given LAC-LNS pair. 959 The Attribute Value field for this AVP has the following format: 961 0 1 2 3 962 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Tie Break Value... 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 ...(64 bits) | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 The Tie Breaker Value is an 8 octet value that is used to choose a 970 single tunnel where both LAC and LNS request a tunnel 971 concurrently. The recipient of a SCCRQ must check to see if a 972 SCCRQ has been sent to the peer, and if so, must compare its Tie 973 Breaker value with the received one. The lower value "wins", and 974 the "loser" MUST silently discard its tunnel. In the case where a 975 tie breaker is present on both sides, and the value is equal, both 976 sides MUST discard their tunnels. 978 If a tie breaker is received, and an outstanding SCCRQ had no tie 979 breaker value, the initiator which included the Tie Breaker AVP 980 "wins". If neither side issues a tie breaker, then two separate 981 tunnels are opened. 983 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 984 this AVP MUST be set to 0. The Length of this AVP is 14. 986 Firmware Revision (SCCRP, SCCRQ) 988 The Firmware Revision AVP, Attribute Type 6, indicates the 989 firmware revision of the issuing device. 991 The Attribute Value field for this AVP has the following format: 993 0 1 994 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Firmware Revision | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 The Firmware Revision is a 2 octet unsigned integer encoded in a 1000 vendor specific format. 1002 For devices which do not have a firmware revision (general purpose 1003 computers running L2TP software modules, for instance), the 1004 revision of the L2TP software module may be reported instead. 1006 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1007 this AVP MUST be set to 0. The Length (before hiding) is 8. 1009 Host Name (SCCRP, SCCRQ) 1011 The Host Name AVP, Attribute Type 7, indicates the name of the 1012 issuing LAC or LNS. 1014 The Attribute Value field for this AVP has the following format: 1016 0 1 2 3 1017 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Host Name ... (arbitrary number of octets) 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 The Host Name is of arbitrary length, but MUST be at least 1 1023 octet. 1025 This name should be as broadly unique as possible; for hosts 1026 participating in DNS [RFC1034], a hostname with fully qualified 1027 domain would be appropriate. 1029 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1030 this AVP MUST be set to 1. The Length of this AVP is 6 plus the 1031 length of the Host Name. 1033 Vendor Name (SCCRP, SCCRQ) 1035 The Vendor Name AVP, Attribute Type 8, contains a vendor specific 1036 (possibly human readable) string describing the type of LAC or LNS 1037 being used. 1039 The Attribute Value field for this AVP has the following format: 1041 0 1 2 3 1042 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | Vendor Name ...(arbitrary number of octets) 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 The Vendor Name is the indicated number of octets representing the 1048 vendor string. Human readable text for this AVP MUST be provided 1049 in the UTF-8 charset using the Default Language [RFC2277]. 1051 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1052 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1053 is 6 plus the length of the Vendor Name. 1055 Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN) 1057 The Assigned Tunnel ID AVP, Attribute Type 9, encodes the ID being 1058 assigned to this tunnel by the sender. 1060 The Attribute Value field for this AVP has the following format: 1062 0 1 1063 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Assigned Tunnel ID | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 The Assigned Tunnel ID is a 2 octet non-zero unsigned integer. 1070 The Assigned Tunnel ID AVP establishes a value used to multiplex 1071 and demultiplex multiple tunnels between the LNS and LAC. The L2TP 1072 peer MUST place this value in the Tunnel ID header field of all 1073 control and data messages that it subsequently transmits over the 1074 associated tunnel. Before the Assigned Tunnel ID AVP is received 1075 from a peer, messages MUST be sent to that peer with a Tunnel ID 1076 value of 0 in the header of all control messages. 1078 In the StopCCN control message, the Assigned Tunnel ID AVP MUST be 1079 the same as the Assigned Tunnel ID AVP first sent to the receiving 1080 peer, permitting the peer to identify the appropriate tunnel even 1081 if a StopCCN is sent before an Assigned Tunnel ID AVP is received. 1083 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1084 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1085 is 8. 1087 Receive Window Size (SCCRQ, SCCRP) 1089 The Receive Window Size AVP, Attribute Type 10, specifies the 1090 receive window size being offered to the remote peer. 1092 The Attribute Value field for this AVP has the following format: 1094 0 1 1095 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Window Size | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 The Window Size is a 2 octet unsigned integer. 1102 If absent, the peer must assume a Window Size of 4 for its 1103 transmit window. The remote peer may send the specified number of 1104 control messages before it must wait for an acknowledgment. 1106 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1107 this AVP MUST be set to 0. The Length of this AVP is 8. 1109 Challenge (SCCRP, SCCRQ) 1111 The Challenge AVP, Attribute Type 11, indicates that the issuing 1112 peer wishes to authenticate the tunnel endpoints using a CHAP- 1113 style authentication mechanism. 1115 The Attribute Value field for this AVP has the following format: 1117 0 1 2 3 1118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Challenge ... (arbitrary number of octets) 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 The Challenge is one or more octets of random data. 1125 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1126 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1127 is 6 plus the length of the Challenge. 1129 Challenge Response (SCCCN, SCCRP) 1131 The Response AVP, Attribute Type 13, provides a response to a 1132 challenge received. 1134 The Attribute Value field for this AVP has the following format: 1136 0 1 2 3 1137 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | Response ... 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 ... (16 octets) | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 The Response is a 16 octet value reflecting the CHAP-style 1149 [RFC1994] response to the challenge. 1151 This AVP MUST be present in an SCCRP or SCCCN if a challenge was 1152 received in the preceeding SCCRQ or SCCRP. For purposes of the ID 1153 value in the CHAP response calculation, the value of the Message 1154 Type AVP for this message is used (e.g. 2 for an SCCRP, and 3 for 1155 an SCCCN). 1157 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1158 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1159 is 22. 1161 4.3.4 Call Management AVPs 1163 Q.931 Cause Code (CDN) 1165 The Q.931 Cause Code AVP, Attribute Type 12, is used to give 1166 additional information in case of unsolicited call disconnection. 1168 The Attribute Value field for this AVP has the following format: 1170 0 1 2 3 1171 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | Cause Code | Cause Msg | Advisory Msg... 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 Cause Code is the returned Q.931 Cause code, and Cause Msg is the 1177 returned Q.931 message code (e.g., DISCONNECT) associated with the 1178 Cause Code. Both values are returned in their native ITU 1179 encodings [DSS1]. An additional ASCII text Advisory Message may 1180 also be included (presence indicated by the AVP Length) to further 1181 explain the reason for disconnecting. 1183 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1184 this AVP MUST be set to 1. The Length of this AVP is 9, plus the 1185 size of the Advisory Message. 1187 Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ) 1189 The Assigned Session ID AVP, Attribute Type 14, encodes the ID 1190 being assigned to this session by the sender. 1192 The Attribute Value field for this AVP has the following format: 1194 0 1 1195 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | Assigned Session ID | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 The Assigned Session ID is a 2 octet non-zero unsigned integer. 1201 The Assigned Session ID AVP is establishes a value used to 1202 multiplex and demultiplex data sent over a tunnel between the LNS 1203 and LAC. The L2TP peer MUST place this value in the Session ID 1204 header field of all control and data messages that it subsequently 1205 transmits over the tunnel that belong to this session. Before the 1206 Assigned Session ID AVP is received from a peer, messages MUST be 1207 sent to that peer with a Session ID of 0 in the header of all 1208 control messages. 1210 In the CDN control message, the same Assigned Session ID AVP first 1211 sent to the receiving peer is used, permitting the peer to 1212 identify the appropriate tunnel even if CDN is sent before an 1213 Assigned Session ID is received. 1215 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1216 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1217 is 8. 1219 Call Serial Number (ICRQ, OCRQ) 1221 The Call Serial Number AVP, Attribute Type 15, encodes an 1222 identifier assigned by the LAC or LNS to this call. 1224 The Attribute Value field for this AVP has the following format: 1226 0 1 2 3 1227 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | Call Serial Number | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 The Call Serial Number is a 32 bit value. 1234 The Call Serial Number is intended to be an easy reference for 1235 administrators on both ends of a tunnel to use when investigating 1236 call failure problems. Call Serial Numbers should be set to 1237 progressively increasing values, which are likely to be unique for 1238 a significant period of time across all interconnected LNSs and 1239 LACs. 1241 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1242 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1243 is 10. 1245 Minimum BPS (OCRQ) 1246 The Minimum BPS AVP, Attribute Type 16, encodes the lowest 1247 acceptable line speed for this call. 1249 The Attribute Value field for this AVP has the following format: 1251 0 1 2 3 1252 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | Minimum BPS | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 The Minimum BPS is a 32 bit value indicates the speed in bits per 1258 second. 1260 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1261 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1262 is 10. 1264 Maximum BPS (OCRQ) 1266 The Maximum BPS AVP, Attribute Type 17, encodes the highest 1267 acceptable line speed for this call. 1269 The Attribute Value field for this AVP has the following format: 1271 0 1 2 3 1272 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | Maximum BPS | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 The Maximum BPS is a 32 bit value indicates the speed in bits per 1278 second. 1280 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1281 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1282 is 10. 1284 Bearer Type (ICRQ, OCRQ) 1286 The Bearer Type AVP, Attribute Type 18, encodes the bearer type 1287 for the incoming or outgoing call. 1289 The Attribute Value field for this AVP has the following format: 1291 0 1 2 3 1292 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 | Reserved for future Bearer Types |A|D| 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 The Bearer Type is a 32-bit bit mask, which indicates the bearer 1298 capability of the call (ICRQ) or required for the call (OCRQ). If 1299 set, bit A indicates that the call refers to an analog channel. If 1300 set, bit D indicates that the call refers to a digital channel. 1301 Both may be set, indicating that the call was either 1302 indistinguishable, or can be placed on either type of channel. 1304 Bits in the Value field of this AVP MUST only be set by the LNS 1305 for an OCRQ if it was set in the Bearer Capabilities AVP received 1306 from the LAC during control connection establishment. 1308 It is valid to set neither the A nor D bits in an ICRQ. Such a 1309 setting may indicate that the call was not received over a 1310 physical link (e.g if the LAC and PPP are located in the same 1311 subsystem). 1313 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1314 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1315 is 10. 1317 Framing Type (ICCN, OCCN, OCRQ) 1319 The Framing Type AVP, Attribute Type 19, encodes the framing type 1320 for the incoming or outgoing call. 1322 The Attribute Value field for this AVP has the following format: 1324 0 1 2 3 1325 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | Reserved for future Framing Types |A|S| 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 The Framing Type is a 32-bit mask, which indicates the type of PPP 1331 framing requested for an OCRQ, or the type of PPP framing 1332 negotiated for an OCCN or ICCN. The framing type MAY be used as an 1333 indication to PPP on the LNS as to what link options to use for 1334 LCP negotiation [RFC1662]. 1336 Bit A indicates asynchronous framing. Bit S indicates synchronous 1337 framing. For an OCRQ, both may be set, indicating that either type 1338 of framing may be used. 1340 Bits in the Value field of this AVP MUST only be set by the LNS 1341 for an OCRQ if it was set in the Framing Capabilities AVP received 1342 from the LAC during control connection establishment. 1344 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1345 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1346 is 10. 1348 Called Number (ICRQ, OCRQ) 1350 The Called Number AVP, Attribute Type 21, encodes the telephone 1351 number to be called for an OCRQ, and the Called number for an 1352 ICRQ. 1354 The Attribute Value field for this AVP has the following format: 1356 0 1 2 3 1357 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | Called Number... (arbitrary number of octets) | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 The Called Number is an ASCII string. Contact between the 1363 administrator of the LAC and the LNS may be necessary to 1364 coordinate interpretation of the value needed in this AVP. 1366 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1367 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1368 is 6 plus the length of the Called Number. 1370 Calling Number (ICRQ) 1372 The Calling Number AVP, Attribute Type 22, encodes the originating 1373 number for the incoming call. 1375 The Attribute Value field for this AVP has the following format: 1377 0 1 2 3 1378 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 | Calling Number... (arbitrary number of octets) | 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 Calling Number is an ASCII string. Contact between the 1384 administrator of the LAC and the LNS may be necessary to 1385 coordinate interpretation of the value in this AVP. 1387 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1388 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1389 is 6 plus the length of the Calling Number. 1391 Sub-Address (ICRQ, OCRQ) 1393 The Sub-Address AVP, Attribute Type 23, encodes additional dialing 1394 information. 1396 The Attribute Value field for this AVP has the following format: 1398 0 1 2 3 1399 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 | Sub-Address ... (arbitrary number of octets) | 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 The Sub-Address is an ASCII string. Contact between the 1405 administrator of the LAC and the LNS may be necessary to 1406 coordinate interpretation of the value in this AVP. 1408 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1409 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1410 is 6 plus the length of the Sub-Address. 1412 (Tx) Connect Speed (ICCN, OCCN) 1414 The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes the 1415 speed of the facility chosen for the connection attempt. 1417 The Attribute Value field for this AVP has the following format: 1419 0 1 2 3 1420 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 | BPS | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 The (Tx) Connect Speed BPS is a 4 octet value indicating the speed 1426 in bits per second. 1428 When the optional Rx Connect Speed AVP is present, the value in 1429 this AVP represents the transmit connect speed, from the 1430 perspective of the LAC (e.g. data flowing from the LAC to the 1431 remote system). When the optional Rx Connect Speed AVP is NOT 1432 present, the connection speed between the remote system and LAC is 1433 assumed to be symmetric and is represented by the single value in 1434 this AVP. 1436 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1437 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1438 is 10. 1440 Rx Connect Speed (ICCN, OCCN) 1442 The Rx Connect Speed AVP, Attribute Type 38, represents the speed 1443 of the connection from the perspective of the LAC (e.g. data 1444 flowing from the remote system to the LAC). 1446 The Attribute Value field for this AVP has the following format: 1448 0 1 2 3 1449 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | BPS (H) | BPS (L) | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 BPS is a 4 octet value indicating the speed in bits per second. 1456 Presence of this AVP implies that the connection speed may be 1457 asymmetric with respect to the transmit connect speed given in the 1458 (Tx) Connect Speed AVP. 1460 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for 1461 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1462 is 10. 1464 Physical Channel ID (ICRQ, OCRP) 1466 The Physical Channel ID AVP, Attribute Type 25, encodes the vendor 1467 specific physical channel number used for a call. 1469 The Attribute Value field for this AVP has the following format: 1471 0 1 2 3 1472 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | Physical Channel ID | 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 Physical Channel ID is a 4 octet value intended to be used for 1478 logging purposes only. 1480 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1481 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1482 is 10. 1484 Private Group ID (ICCN) 1486 The Private Group ID AVP, Attribute Type 37, is used by the LAC to 1487 indicate that this call is to be associated with a particular 1488 customer group. 1490 The Attribute Value field for this AVP has the following format: 1492 0 1 2 3 1493 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | Private Group ID ... (arbitrary number of octets) | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 The Private Group ID is a string of octets of arbitrary length. 1500 The LNS MAY treat the PPP session as well as network traffic through 1501 this session in a special manner determined by the peer. For example, 1502 if the LNS is individually connected to several private networks 1503 using unregistered addresses, this AVP may be included by the LAC to 1504 indicate that a given call should be associated with one of the 1505 private networks. 1507 The Private Group ID is a string corresponding to a table in the LNS 1508 that defines the particular characteristics of the selected group. A 1509 LAC MAY determine the Private Group ID from a RADIUS response, local 1510 configuration, or some other source. 1512 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for this 1513 AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 1514 plus the length of the Private Group ID. 1516 Sequencing Required (ICCN, OCCN) 1518 The Sequencing Required AVP, Attribute Type 39, indicates to the LNS 1519 that Sequence Numbers MUST always be present on the data channel. 1521 This AVP has no Attribute Value field. 1523 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1524 this AVP MUST be set to 1. The Length of this AVP is 6. 1526 4.3.5 Proxy LCP and Authentication AVPs 1528 The LAC may have answered the call and negotiated LCP with the remote 1529 system, perhaps in order to establish the system's apparent identity. 1530 In this case, these AVPs may be included to indicate the link 1531 properties the remote system initially requested, properties the 1532 remote system and LAC ultimately negotiated, as well as PPP 1533 authentication information sent and received by the LAC. This 1534 information may be used to initiate the PPP LCP and authentication 1535 systems on the LNS, allowing PPP to continue without renegotiation of 1536 LCP. Note that the LNS policy may be to enter an additional round of 1537 LCP negotiation and/or authentication if the LAC is not trusted. 1539 Initial Received LCP CONFREQ (ICCN) 1541 In the Initial Received LCP CONFREQ AVP, Attribute Type 26, 1542 provides the LNS with the Initial CONFREQ received by the LAC from 1543 the PPP Peer. 1545 The Attribute Value field for this AVP has the following format: 1547 0 1 2 3 1548 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | LCP CONFREQ... (arbitrary number of octets) | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 LCP CONFREQ is a copy of the body of the initial CONFREQ received, 1554 starting at the first option within the body of the LCP message. 1556 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1557 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1558 is 6 plus the length of the CONFREQ. 1560 Last Sent LCP CONFREQ (ICCN) 1562 In the Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the 1563 LNS with the Last CONFREQ sent by the LAC to the PPP Peer. 1565 The Attribute Value field for this AVP has the following format: 1567 0 1 2 3 1568 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | LCP CONFREQ... (arbitrary number of octets) | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 The LCP CONFREQ is a copy of the body of the final CONFREQ sent to 1574 the client to complete LCP negotiation, starting at the first 1575 option within the body of the LCP message. 1577 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1578 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1579 is 6 plus the length of the CONFREQ. 1581 Last Received LCP CONFREQ (ICCN) 1583 The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the 1584 LNS with the Last CONFREQ received by the LAC from the PPP Peer. 1586 The Attribute Value field for this AVP has the following format: 1588 0 1 2 3 1589 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 | LCP CONFREQ... (arbitrary number of octets) | 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 The LCP CONFREQ is a copy of the body of the final CONFREQ 1595 received from the client to complete LCP negotiation, starting at 1596 the first option within the body of the LCP message. 1598 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1599 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1600 is 6 plus the length of the CONFREQ. 1602 Proxy Authen Type (ICCN) 1604 The Proxy Authen Type AVP, Attribute Type 29, determines if proxy 1605 authentication should be used. 1607 The Attribute Value field for this AVP has the following format: 1609 0 1 1610 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 | Authen Type | 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 Authen Type is a 2 octet unsigned integer, holding: 1617 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1618 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1619 is 8. 1621 Defined Authen Type values are: 1622 0 - Reserved 1623 1 - Textual username/password exchange 1624 2 - PPP CHAP 1625 3 - PPP PAP 1626 4 - No Authentication 1627 5 - Microsoft CHAP Version 1 (MSCHAPv1) 1628 This AVP MUST be present if proxy authentication is to be 1629 utilized. If it is not present, then it is assumed that this 1630 peer cannot perform proxy authentication, requiring 1631 a restart of the authentication phase at the LNS if the client 1632 has already entered this phase with the 1633 LAC (which may be determined by the Proxy LCP AVP if present).. 1635 Associated AVPs for each type of authentication follow. 1637 Proxy Authen Name (ICCN) 1639 The Proxy Authen Name AVP, Attribute Type 30, specifies the name 1640 of the authenticating client when using proxy authentication. 1642 The Attribute Value field for this AVP has the following format: 1644 0 1 2 3 1645 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | Authen Name... (arbitrary number of octets) | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 Authen Name is a string of octets of arbitrary length. It 1651 contains the name specified in the client's authentication 1652 response. 1654 This AVP MUST be present in messages containing a Proxy Authen 1655 Type AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable 1656 to employ AVP hiding for obscuring the cleartext name. 1658 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1659 this AVP MUST be set to 0. The Length (before hiding) is 6 plus 1660 the length of the cleartext name. 1662 Proxy Authen Challenge (ICCN) 1664 The Proxy Authen Challenge AVP, Attribute Type 31, specifies the 1665 challenge sent by the LAC to the PPP Peer, when using proxy 1666 authentication. 1668 The Attribute Value field for this AVP has the following format: 1670 0 1 2 3 1671 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | Challenge... (arbitrary number of octets) | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 The Challenge is a string of one or more octets. 1677 This AVP MUST be present for Proxy Authen Types 2 and 5. The 1678 Challenge field contains the CHAP challenge presented to the 1679 client by the LAC. 1681 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1682 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1683 is 6, plus the length of the Challenge. 1685 Proxy Authen ID (ICCN) 1687 The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value 1688 of the PPP Authentication that was started between the LAC and the 1689 PPP Peer, when proxy authentication is being used. 1691 The Attribute Value field for this AVP has the following format: 1693 0 1 1694 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | Reserved | ID | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1699 ID is a 2 octet unsigned integer, the most significant octet MUST 1700 be 0. 1702 The Proxy Authen ID AVP MUST be present for Proxy authen types 2, 1703 3 and 5. For 2 and 5, the ID field contains the byte ID value 1704 presented to the client by the LAC in its Challenge. For 3, it is 1705 the Identifier value of the Authenticate-Request. 1707 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1708 this AVP MUST be set to 0. 1710 Proxy Authen Response (ICCN) 1712 The Proxy Authen Response AVP, Attribute Type 33, specifies the 1713 PPP Authentication response received by the LAC from the PPP Peer, 1714 when proxy authentication is used. 1716 The Attribute Value field for this AVP has the following format: 1718 0 1 2 3 1719 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 | Response... (arbitrary number of octets) | 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 The Response is a string of octets. 1725 This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The 1726 Response field contains the client's response to the challenge. 1727 For Proxy authen types 2 and 5, this field contains the response 1728 value received by the LAC. For types 1 or 3, it contains the clear 1729 text password received from the client by the LAC. In the case of 1730 cleartext passwords, AVP hiding is recommended. 1732 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1733 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1734 is 6 plus the length of the Response. 1736 4.3.6 Call Status AVPs 1738 Call Errors (WEN) 1740 The Call Errors AVP, Attribute Type 34, is used by the LAC to send 1741 error information to the LNS. 1743 The Attribute Value field for this AVP has the following format: 1745 0 1 2 3 1746 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 | Reserved | CRC Errors (H) | 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | CRC Errors (L) | Framing Errors (H) | 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 | Framing Errors (L) | Hardware Overruns (H) | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 | Hardware Overruns (L) | Buffer Overruns (H) | 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 | Buffer Overruns (L) | Time-out Errors (H) | 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 | Time-out Errors (L) | Alignment Errors (H) | 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 | Alignment Errors (L) | 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 The following fields are defined: 1765 Reserved - Not used, MUST be 0 1766 CRC Errors - Number of PPP frames received with CRC errors 1767 since call was established 1768 Framing Errors - Number of improperly framed PPP packets 1769 received 1770 Hardware Overruns - Number of receive buffer over-runs since 1771 call was established 1772 Buffer Overruns - Number of buffer over-runs detected since 1773 call was established 1774 Time-out Errors - Number of time-outs since call was 1775 established 1776 Alignment Errors - Number of alignment errors since call was 1777 established 1779 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this 1780 AVP MUST be set to 1. The Length (before hiding) of this AVP is 32. 1782 ACCM (SLI) 1784 The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC 1785 of the ACCM negotiated with the PPP Peer by the LNS. 1787 The Attribute Value field for this AVP has the following format: 1789 0 1 2 3 1790 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | Reserved | Send ACCM (H) | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | Send ACCM (L) | Receive ACCM (H) | 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | Receive ACCM (L) | 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 Send ACCM and Receive ACCM are each 4 octet values preceeded by a 1800 2 octet reserved quantity. The send ACCM value should be used by 1801 the LAC to process packets it sends on the connection. The receive 1802 ACCM value should be used by the LAC to process incoming packets 1803 on the connection. The default values used by the LAC for both 1804 these fields are 0xFFFFFFFF. The LAC should honor these fields 1805 unless it has specific configuration information to indicate that 1806 the requested mask must be modified to permit operation. 1808 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for 1809 this AVP MUST be set to 1. The Length of this AVP is 16. 1811 5.0 Protocol Operation 1813 The necessary setup for tunneling a PPP session with L2TP consists of 1814 two steps, (1) establishing the Control Connection for a Tunnel, and 1815 (2) establishing a Session as triggered by an incoming or outgoing 1816 call request. The Tunnel and corresponding Control Connection MUST be 1817 established before an incoming or outgoing call is initiated. An L2TP 1818 Session MUST be established before L2TP can begin to tunnel PPP 1819 frames. Multiple Sessions may exist across a single Tunnel and 1820 multiple Tunnels may exist between the same LAC and LNS.. 1822 +-----+ +-----+ 1823 | |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~| | 1824 | LAC | | LNS | 1825 | #######Control Connection######## | 1826 [Remote] | | | | 1827 [System]------Call----------*============L2TP Session=============* | 1828 PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | 1829 | | | | 1830 [Remote] | | | | 1831 [System]------Call----------*============L2TP Session=============* | 1832 PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | 1833 | | | | 1834 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | 1835 +-----+ +-----+ 1837 Figure 5.1 Tunneling PPP 1839 5.1 Control Connection Establishment 1841 The Control Connection is the initial connection that must be 1842 achieved between an LAC and LNS before sessions may be brought up. 1843 Establishment of the control connection includes securing the 1844 identity of the peer, as well as identifying the peer's L2TP version, 1845 framing, and bearer capabilities, etc. 1847 A three message exchange is utilized to setup the control connection. 1848 Following is a typical message exchange: 1850 LAC or LNS LAC or LNS 1851 ---------- ---------- 1852 SCCRQ -> 1853 <- SCCRP 1854 SCCCN -> 1855 <- ZLB ACK 1857 The ZLB ACK is sent if there are no further messages waiting in queue 1858 for that peer. 1860 5.1.1 Tunnel Authentication 1862 L2TP incorporates a simple, optional, CHAP-like [RFC1994] tunnel 1863 authentication system during control connection establishment. If 1864 an LAC or LNS wishes to authenticate the identity of the peer it 1865 is contacting or being contacted by, a Challenge AVP is included 1866 in the SCCRQ or SCCRP message. If a Challenge AVP is received in 1867 an SCCRQ or SCCRP, a Challenge Response AVP MUST be sent in the 1868 following SCCRP or SCCCN, respectively. If the expected response 1869 and response received from a peer does not match, establishment of 1870 the tunnel MUST be disallowed. 1872 To participate in tunnel authentication, a single shared secret 1873 MUST exist between the LAC and LNS. This is the same shared secret 1874 used for AVP hiding (see Section 4.2). See Section 4.3.3 for 1875 details on construction of the Challenge and Response AVPs. 1877 5.2 Session Establishment 1879 After successful control connection establishment, individual 1880 sessions may be created. Each session corresponds to single PPP 1881 stream between the LAC and LNS. Unlike control connection 1882 establishment, session establishment is directional with respect to 1883 the LAC and LNS. The LAC requests the LNS to accept a session for an 1884 incoming call, and the LNS requests the LAC to accept a session for 1885 placing an outgoing call. 1887 5.2.1 Incoming Call Establishment 1889 A three message exchange is employed to setup the session. 1890 Following is a typical sequence of events: 1892 LAC LNS 1893 --- --- 1894 (Call 1895 Detected) 1897 ICRQ -> 1898 <- ICRP 1899 ICCN -> 1900 <- ZLB ACK 1902 The ZLB ACK is sent if there are no further messages waiting in 1903 queue for that peer. 1905 5.2.2 Outgoing Call Establishment 1907 A three message exchange is employed to setup the session. 1908 Following is a typical sequence of events: 1910 LAC LNS 1911 --- --- 1912 <- OCRQ 1913 OCRP -> 1915 (Perform 1916 Call 1917 Operation) 1919 OCCN -> 1920 <- ZLB ACK 1922 The ZLB ACK is sent if there are no further messages waiting in 1923 queue for that peer. 1925 5.3 Forwarding PPP Frames 1927 Once tunnel establishment is complete, PPP frames from the remote 1928 system are received at the LAC, stripped of CRC, link framing, and 1929 transparency bytes, encapsulated in L2TP, and forwarded over the 1930 appropriate tunnel. The LNS receives the L2TP packet, and processes 1931 the encapsulated PPP frame as if it were received on a local PPP 1932 interface. 1934 The sender of a message associated with a particular session and 1935 tunnel places the Session ID and Tunnel ID (specified by its peer) in 1936 the Session ID and Tunnel ID header for all outgoing messages. In 1937 this manner, PPP frames are multiplexed and demultiplexed over a 1938 single tunnel between a given LNS-LAC pair. Multiple tunnels may 1939 exist between a given LNS-LAC pair, and multiple sessions may exist 1940 within a tunnel. 1942 The value of 0 for Session ID and Tunnel ID is special and MUST NOT 1943 be used as an Assigned Session ID or Assigned Tunnel ID. For the 1944 cases where a Session ID has not yet been assigned by the peer (i.e., 1945 during establishment of a new session or tunnel), the Session ID 1946 field MUST be sent as 0, and the Assigned Session ID AVP within the 1947 message MUST be used to identify the session. Similarly, for cases 1948 where the Tunnel ID has not yet been assigned from the peer, the 1949 Tunnel ID MUST be sent as 0 and Assigned Tunnel ID AVP used to 1950 identify the tunnel. 1952 5.4 Using Sequence Numbers on the Data Channel 1954 Sequence numbers are defined in the L2TP header for control messages 1955 and optionally for data messages (see Section 3.1). These are used to 1956 provide a reliable control message transport (see Section 5.8) and 1957 optional data message sequencing. Each peer maintains separate 1958 sequence numbers for the control connection and each individual data 1959 session within a tunnel. 1961 Unlike the L2TP control channel, the L2TP data channel does not use 1962 sequence numbers to retransmit lost data messages. Rather, data 1963 messages may use sequence numbers to detect lost packets and/or 1964 restore the original sequence of packets that may have been reordered 1965 during transport. The LAC may request that sequence numbers be 1966 present in data messages via the Sequencing Required AVP (see Section 1967 4.3.6). If this AVP is present during session setup, sequence numbers 1968 MUST be present at all times. If this AVP is not present, sequencing 1969 presence is under control of the LNS. The LNS controls enabling and 1970 disabling of sequence numbers by sending a data message with or 1971 without sequence numbers present at any time during the life of a 1972 session. Thus, if the LAC receives a data message without sequence 1973 numbers present, it MUST stop sending sequence numbers in future data 1974 messages. If the LAC receives a data message with sequence numbers 1975 present, it MUST begin sending sequence numbers in future outgoing 1976 data messages. If the LNS enables sequencing after disabling it 1977 earlier in the session, the sequence number state picks up where it 1978 left off before. 1980 The LNS may initiate disabling of sequencing at any time during the 1981 session (including the first data message sent). It is recommended 1982 that for connections where reordering or packet loss may occur, 1983 sequence numbers always be enabled during the initial negotiation 1984 stages of PPP and disabled only when and if the risk is considered 1985 acceptable. For example, if the PPP session being tunneled is not 1986 utilizing any stateful compression or encryption protocols and is 1987 only carrying IP (as determined by the PPP NCPs that are 1988 established), then the LNS might decide to disable sequencing as IP 1989 is tolerant to datagram loss and reordering. 1991 5.5 Keepalive (Hello) 1993 A keepalive mechanism is employed by L2TP in order to differentiate 1994 tunnel outages from extended periods of no control or data activity 1995 on a tunnel. This is accomplished by injecting Hello control messages 1996 (see Section 6.5) after a specified period of time has elapsed since 1997 the last data or control message was received on a tunnel. As for any 1998 other control message, if the Hello message is not reliably delivered 1999 then the tunnel is declared down and is reset. The transport reset 2000 mechanism along with the injection of Hello messages ensures that a 2001 connectivity failure between the LNS and the LAC will be detected at 2002 both ends of a tunnel. 2004 5.6 Session Teardown 2006 Session teardown may be initiated by either the LAC or LNS and is 2007 accomplished by sending a CDN control message. After the last session 2008 is cleared, the control connection MAY be torn down as well (and 2009 typically is). Following is an example of a typical control message 2010 exchange: 2012 LAC or LNS LAC or LNS 2014 CDN -> 2015 (Clean up) 2017 <- ZLB ACK 2018 (Clean up) 2020 5.7 Control Connection Teardown 2022 Control connection teardown may be initiated by either the LAC or LNS 2023 and is accomplished by sending a single StopCCN control message. The 2024 receiver of a StopCCN MUST send a ZLB ACK to acknowledge receipt of 2025 the message and maintain enough control connection state to properly 2026 accept StopCCN retransmissions over at least a full retransmission 2027 cycle (in case the ZLB ACK is lost). The recommended time for a full 2028 retransmission cycle is 31 seconds (see section 5.8). Following is an 2029 example of a typical control message exchange: 2031 LAC or LNS LAC or LNS 2033 StopCCN -> 2034 (Clean up) 2036 <- ZLB ACK 2037 (Wait) 2038 (Clean up) 2040 An implementation may shut down an entire tunnel and all sessions on 2041 the tunnel by sending the StopCCN. Thus, it is not necessary to clear 2042 each session individually when tearing down the whole tunnel. 2044 5.8 Reliable Delivery of Control Messages 2046 L2TP provides a lower level reliable transport service for all 2047 control messages. The Nr and Ns fields of the control message header 2048 (see section 3.1) belong to this transport. The upper level 2049 functions of L2TP are not concerned with retransmission or ordering 2050 of control messages. The reliable control message is a sliding window 2051 transport that provides control message retransmission and congestion 2052 control. Each peer maintains separate sequence number state for the 2053 control connection within a tunnel. 2055 The message sequence number, Ns, begins at 0. Each subsequent message 2056 is sent with the next increment of the sequence number. The sequence 2057 number is thus a free running counter represented modulo 65536. The 2058 sequence number in the header of a received message is considered 2059 less than or equal to the last received number if its value lies in 2060 the range of the last received number and the preceding 32767 values, 2061 inclusive. For example, if the last received sequence number was 15, 2062 then messages with sequence numbers 0 through 15, as well as 32784 2063 through 65535, would be considered less than or equal. Such a message 2064 would be considered a duplicate of a message already received and 2065 dropped silently. 2067 All control messages take up one slot in the control message sequence 2068 number space, except the ZLB acknowledgement. Thus, Ns is not 2069 incremented after a ZLB message is sent. 2071 The last received message number, Nr, is used to acknowledge messages 2072 received by an L2TP peer. It contains the sequence number of the 2073 message the peer expects to receive next (e.g. the last Ns of a non- 2074 ZLB message received plus 1, modulo 65536). While the Nr in a 2075 received ZLB is used to flush messages from the local retransmit 2076 queue (see below), Nr of the next message sent is not be updated by 2077 the Ns of the ZLB. 2079 The reliable transport at a receiving peer is responsible for making 2080 sure that control messages are delivered in order and without 2081 duplication to the upper level. Messages arriving out of order may be 2082 queued for in-order delivery when the missing messages are received, 2083 or they may be discarded requiring a retransmission by the peer. 2085 Each tunnel maintains a queue of control messages to be transmitted 2086 to its peer. The message at the front of the queue is sent with a 2087 given Ns value, and is held until a control message arrives from the 2088 peer in which the Nr field indicates receipt of this message. After a 2089 period of time (a recommended default is 1 second) passes without 2090 acknowledgement, the message is retransmitted. The retransmitted 2091 message contains the same Ns value, but the Nr value MUST be updated 2092 with the sequence number of the next expected message. 2094 Each subsequent retransmission of a message MUST employ an 2095 exponential backoff interval. Thus, if the first retransmission 2096 occurred after 1 second, the next retransmission should occur after 2 2097 seconds has elapsed, then 4 seconds, etc. An implementation MAY place 2098 a cap upon the maximum interval between retransmissions. This cap 2099 MUST be no less than 8 seconds per retransmission. If no peer 2100 response is detected after several retransmissions, (a recommended 2101 default is 5, but SHOULD be configurable), the tunnel and all 2102 sessions within MUST be cleared. 2104 When a tunnel is being shut down for reasons other than loss of 2105 connectivity, the state and reliable delivery mechanisms MUST be 2106 maintained and operated for the full retransmission interval after 2107 the final message exchange has occurred. 2109 A sliding window mechanism is used for control message transmission. 2110 Consider two peers A & B. Suppose A specifies a Receive Window Size 2111 AVP with a value of N in the SCCRQ or SCCRP messages. B is now 2112 allowed to have up to N outstanding control messages. Once N have 2113 been sent, it must wait for an acknowledgment that advances the 2114 window before sending new control messages. An implementation may 2115 support a receive window of only 1 (i.e., by sending out a Receive 2116 Window Size AVP with a value of 1), but MUST accept a window of up to 2117 4 from its peer (e.g. have the ability to send 4 messages before 2118 backing off). A value of 0 for the Receive Window Size AVP is 2119 invalid. 2121 When retransmitting control messages, a slow start and congestion 2122 avoidance window adjustment procedure SHOULD be utilized. The 2123 recommended procedure for this is described in Appendix A. 2125 A peer MUST NOT withhold acknowledgment of messages as a technique 2126 for flow controlling control messages. An L2TP implementation is 2127 expected to be able to keep up with incoming control messages, 2128 possibly responding to some with errors reflecting an inability to 2129 honor the requested action. 2131 Appendix B contains examples of control message transmission, 2132 acknowledgement, and retransmission. 2134 6.0 Control Connection Protocol Specification 2136 The following control connection messages are used to establish, 2137 clear and maintain L2TP tunnels. All data is sent in network order 2138 (high order octets first). Any "reserved" or "empty" fields MUST be 2139 sent as 0 values to allow for protocol extensibility. 2141 6.1 Start-Control-Connection-Request (SCCRQ) 2143 Start-Control-Connection-Request (SCCRQ) is a control message used to 2144 initialize a tunnel between an LNS and an LAC. It is sent by either 2145 the LAC or the LNS to being the tunnel establishement process. 2147 The following AVPs MUST be present in the SCCRQ: 2149 Message Type AVP 2150 Protocol Version 2151 Host Name 2152 Framing Capabilities 2153 Assigned Tunnel ID 2155 The Following AVPs MAY be present in the SCCRQ: 2157 Bearer Capabilities 2158 Receive Window Size 2159 Challenge 2160 Tie Breaker 2161 Firmware Revision 2162 Vendor Name 2164 6.2 Start-Control-Connection-Reply (SCCRP) 2166 Start-Control-Connection-Reply (SCCRP) is a control message sent in 2167 reply to a received SCCRQ message. SCCRP is used to indicate that the 2168 SCCRQ was accepted and establishment of the tunnel should continue. 2170 The following AVPs MUST be present in the SCCRP: 2172 Message Type 2173 Protocol Version 2174 Framing Capabilities 2175 Host Name 2176 Assigned Tunnel ID 2178 The following AVPs MAY be present in the SCCRP: 2180 Bearer Capabilities 2181 Firmware Revision 2182 Vendor Name 2183 Receive Window Size 2184 Challenge 2185 Challenge Response 2187 6.3 Start-Control-Connection-Connected (SCCCN) 2189 Start-Control-Connection-Connected (SCCCN) is a control message sent 2190 in reply to an SCCRP. SCCCN completes the tunnel establishment 2191 process. 2193 The following AVP MUST be present in the SCCCN: 2195 Message Type 2197 The following AVP MAY be present in the SCCCN: 2199 Challenge Response 2201 6.4 Stop-Control-Connection-Notification (StopCCN) 2203 Stop-Control-Connection-Notification (StopCCN) is a control message 2204 sent by either the LAC or LNS to inform its peer that the tunnel is 2205 being shutdown and the control connection should be closed. In 2206 addition, all active sessions are implicitly cleared (without sending 2207 any explicit call control messages). The reason for issuing this 2208 request is indicated in the Result Code AVP. There is no explicit 2209 reply to the message, only the implicit ACK that is received by the 2210 reliable control message transport layer. 2212 The following AVPs MUST be present in the StopCCN: 2214 Message Type 2215 Assigned Tunnel ID 2216 Result Code 2218 6.5 Hello (HELLO) 2220 The Hello (HELLO) message is an L2TP control message sent by either 2221 peer of a LAC-LNS control connection. This control message is used as 2222 a "keepalive" for the tunnel. 2224 The sending of HELLO messages and the policy for sending them are 2225 left up to the implementation. A peer MUST NOT expect HELLO messages 2226 at any time or interval. As with all messages sent on the control 2227 connection, the receiver will return either a ZLB ACK or an 2228 (unrelated) message piggybacking the necessary acknowledgement 2229 information. 2231 Since a HELLO is a control message, and control messages are reliably 2232 sent by the lower level transport, this keepalive function operates 2233 by causing the transport level to reliably deliver a message. If a 2234 media interruption has occurred, the reliable transport will be 2235 unable to deliver the HELLO across, and will clean up the tunnel. 2237 Keepalives for the tunnel MAY be implemented by sending a HELLO if a 2238 period of time (a recommended default is 60 seconds, but SHOULD be 2239 configurable) has passed without receiving any message (data or 2240 control) from the peer. 2242 HELLO messages are global to the tunnel. The Session ID in a HELLO 2243 message MUST be 0. 2245 The Following AVP MUST be present in the HELLO message: 2247 Message Type 2249 6.6 Incoming-Call-Request (ICRQ) 2251 Incoming-Call-Request (ICRQ) is a control message sent by the LAC to 2252 the LNS when an incoming call is detected. It is the first in a three 2253 message exchange used for establishing a session within an L2TP 2254 tunnel. 2256 ICRQ is used to indicate that a session is to be established between 2257 the LAC and LNS for this call and provides the LNS with parameter 2258 information for the session. The LAC may defer answering the call 2259 until it has received an ICRP from the LNS indicating that the 2260 session should be established. This mechanism allows the LNS to 2261 obtain sufficient information about the call before determining 2262 whether it should be answered or not. Alternatively, the LAC may 2263 answer the call, negotiate LCP and PPP authentication, and use the 2264 information gained to choose the LNS. In this case, the call has 2265 already been answered by the time the ICRP message is received; the 2266 LAC simply spoofs the "call indication" and "call answer" steps in 2267 this case. 2269 The following AVPs MUST be present in the ICRQ: 2271 Message Type 2272 Assigned Session ID 2273 Call Serial Number 2275 The following AVPs MAY be present in the ICRQ: 2277 Bearer Type 2278 Physical Channel ID 2279 Calling Number 2280 Called Number 2281 Sub-Address 2283 6.7 Incoming-Call-Reply (ICRP) 2285 Incoming-Call-Reply (ICRP) is a control message sent by the LNS to 2286 the LAC in response to a received ICRQ message. It is the second in 2287 the three message exchange used for establishing sessions within an 2288 L2TP tunnel. 2290 ICRP is used to indicate that the ICRQ was successful and for the LAC 2291 to answer the call if it has not already done so. It also allows the 2292 LNS to indicate necessary parameters for the L2TP session. 2294 The following AVPs MUST be present in the ICRP: 2296 Message Type 2297 Assigned Session ID 2299 6.8 Incoming-Call-Connected (ICCN) 2301 Incoming-Call-Connected (ICCN) is a control message sent by the LAC 2302 to the LNS in response to a received ICRP message. It is the third 2303 message in the three message exchange used for establishing sessions 2304 within an L2TP tunnel. 2306 ICCN is used to indicate that the ICRP was accepted, the call has 2307 been answered, and that the L2TP session should move to the 2308 established state. It also provides additional information to the 2309 LNS about parameters used for the answered call (parameters that may 2310 not always available at the time the ICRQ is issued). 2312 The following AVPs MUST be present in the ICCN: 2314 Message Type 2315 (Tx) Connect Speed 2316 Framing Type 2318 The following AVPs MAY be present in the ICCN: 2320 Initial Received LCP CONFREQ 2321 Last Sent LCP CONFREQ 2322 Last Received LCP CONFREQ 2323 Proxy Authen Type 2324 Proxy Authen Name 2325 Proxy Authen Challenge 2326 Proxy Authen ID 2327 Proxy Authen Response 2328 Private Group ID 2329 Rx Connect Speed 2330 Sequencing Required 2332 6.9 Outgoing-Call-Request (OCRQ) 2334 Outgoing-Call-Request (OCRQ) is a control message sent by the LNS to 2335 the LAC to indicate that an outbound call from the LAC is to be 2336 established. It is the first in a three message exchange used for 2337 establishing a session within an L2TP tunnel. 2339 OCRQ is used to indicate that a session is to be established between 2340 the LNS and LAC for this call and provides the LAC with parameter 2341 information for both the L2TP session, and the call that is to be 2342 placed 2344 An LNS MUST have received a Bearer Capabilities AVP during tunnel 2345 establishment from an LAC in order to request an outgoing call to 2346 that LAC. 2348 The following AVPs MUST be present in the OCRQ: 2350 Message Type 2351 Assigned Session ID 2352 Call Serial Number 2353 Minimum BPS 2354 Maximum BPS 2355 Bearer Type 2356 Framing Type 2357 Called Number 2359 The following AVPs MAY be present in the OCRQ: 2361 Sub-Address 2363 6.10 Outgoing-Call-Reply (OCRP) 2365 Outgoing-Call-Reply (OCRP) is a control message sent by the LAC to 2366 the LNS in response to a received OCRQ message. It is the second in a 2367 three message exchange used for establishing a session within an L2TP 2368 tunnel. 2370 OCRP is used to indicate that the LAC is able to attempt the outbound 2371 call and returns certain parameters regarding the call attempt. 2373 The following AVPs MUST be present in the OCRP: 2375 Message Type 2376 Assigned Session ID 2378 The following AVPs MAY be present in the OCRP: 2380 Physical Channel ID 2382 6.11 Outgoing-Call-Connected (OCCN) 2384 Outgoing-Call-Connected (OCCN) is a control message sent by the LAC 2385 to the LNS following the OCRP and after the outgoing call has been 2386 completed. It is the final message in a three message exchange used 2387 for establishing a session within an L2TP tunnel. 2389 OCCN is used to indicate that the result of a requested outgoing call 2390 was successful. It also provides information to the LNS about the 2391 particular parameters obtained after the call was established. 2393 The following AVPs MUST be present in the OCCN: 2395 Message Type 2396 (Tx) Connect Speed 2397 Framing Type 2399 The following AVPs MAY be present in the OCCN: 2401 Rx Connect Speed 2402 Sequencing Required 2404 6.12 Call-Disconnect-Notify (CDN) 2406 The Call-Disconnect-Notify (CDN) message is an L2TP control message 2407 sent by either the LAC or LNS to request disconnection of a specific 2408 call within the tunnel. Its purpose is to inform the peer of the 2409 disconnection and the reason why the disconnection occurred. The peer 2410 MUST clean up any resources, and does not send back any indication of 2411 success or failure for such cleanup. 2413 The following AVPs MUST be present in the CDN: 2415 Message Type 2416 Result Code 2417 Assigned Session ID 2419 The following AVPs MAY be present in the CDN: 2421 Q.931 Cause Code 2423 6.13 WAN-Error-Notify (WEN) 2425 The WAN-Error-Notify message is an L2TP control message sent by the 2426 LAC to the LNS to indicate WAN error conditions (conditions that 2427 occur on the interface supporting PPP). The counters in this message 2428 are cumulative. This message should only be sent when an error 2429 occurs, and not more than once every 60 seconds. The counters are 2430 reset when a new call is established. 2432 The following AVPs MUST be present in the WEN: 2434 Message Type 2435 Call Errors 2437 6.14 Set-Link-Info (SLI) 2439 The Set-Link-Info message is an L2TP control message sent by the LNS 2440 to the LAC to set PPP-negotiated options. These options can change 2441 at any time during the life of the call, thus the LAC MUST be able to 2442 update its internal call information and behavior on an active PPP 2443 session. 2445 The following AVPs MUST be present in the SLI: 2447 Message Type 2448 ACCM 2450 7.0 Control Connection State Machines 2452 The control messages defined in section 6 are exchanged by way of 2453 state tables defined in this section. Tables are defined for incoming 2454 call placement, outgoing call placement, as well as for initiation of 2455 the tunnel itself. The state tables do not encode timeout and 2456 retransmission behavior, as this is handled in the underlying 2457 semantics defined in Section 5.8. 2459 7.1 Control Connection Protocol Operation 2461 This section describes the operation of various L2TP control 2462 connection functions and the Control Connection messages which are 2463 used to support them. 2465 Receipt of an invalid or unrecoverably malformed control message 2466 should be logged appropriately and the control connection cleared to 2467 ensure recovery to a known state. The control connection may then be 2468 restarted by the initator. 2470 An invalid control message is defined as a message which contains a 2471 Message Type that is marked mandatory (see Section 4.3.1) and is 2472 unknown to the implementation, or a control message that is received 2473 in an improper sequence (e.g. an SCCCN sent in reply to an SCCRQ). 2475 Examples of a malformed control message include one that has an 2476 invalid value in its header, contains an AVP that is formatted 2477 incorrectly or whose value is out of range, or a message that is 2478 missing a required AVP. A control message with a malformed header 2479 should be discarded. A control message with an invalid AVP should 2480 look to the M-bit for that AVP to determine whether the error is 2481 recoverable or not. 2483 A malformed yet recoverable non-mandatory (M-bit is not set) AVP 2484 within a control message should be treated in a similar manner as an 2485 unrecognized non-mandatory AVP. Thus, if a malformed AVP is recevied 2486 with the M-bit set, the session or tunnel should be terminated with a 2487 proper Result or Error Code sent. If the M-bit is not set, the AVP 2488 should be ignored (with the exception of logging a local error 2489 message) and the message accepted. 2491 This MUST NOT be considered a license to send malformed AVPs, but 2492 simply a guide towards how to handle an improperly formatted message 2493 if one is received. It is impossible to list all potential 2494 malformations of a given message and give advice for each. That said, 2495 one example of a recoverable, malformed AVP might be if the Rx 2496 Connect Speed AVP, attribute 38, is received with a length of 8 2497 rather than 10 and the BPS given in 2 octets rather than 4. Since the 2498 Rx Connect Speed is non-mandatory, this condition should not be 2499 considered catastrophic. As such, the control message should be 2500 accepted as if the AVP had not been received (with the exception of a 2501 local error message being logged). 2503 In several cases in the following tables, a protocol message is sent, 2504 and then a "clean up" occurs. Note that regardless of the initiator 2505 of the tunnel destruction, the reliable delivery mechanism must be 2506 allowed to run (see Section 5.8) before destroying the tunnel. This 2507 permits the tunnel management messages to be reliably delivered to 2508 the peer. 2510 Appendix B.1 contains an example of lock-step tunnel establishment. 2512 7.2 Control Connection States 2514 The L2TP control connection protocol is not distinguishable between 2515 the LNS and LAC, but is distinguishable between the originator and 2516 receiver. The originating peer is the one which first initiates 2517 establishment of the tunnel (in a tie breaker situation, this is the 2518 winner of the tie). Since either LAC or LNS can be the originator, a 2519 collision can occur. See the Tie Breaker AVP in Section 4.3.3 for a 2520 description of this and its resolution. 2522 7.2.1 Control Connection Establishment 2524 State Event Action New State 2525 ----- ----- ------ --------- 2526 idle Local Send SCCRQ wait-ctl-reply 2527 Open request 2529 idle Receive SCCRQ, Send SCCRP wait-ctl-conn 2530 acceptable 2532 idle Receive SCCRQ, Send StopCCN, idle 2533 not acceptable Clean up 2535 idle Receive SCCRP Send StopCCN idle 2536 Clean up 2538 idle Receive SCCCN Clean up idle 2540 wait-ctl-reply Receive SCCRP, Send SCCCN, established 2541 acceptable Send tunnel-open 2542 event to waiting 2543 sessions 2545 wait-ctl-reply Receive SCCRP, Send StopCCN, idle 2546 not acceptable Clean up 2548 wait-ctl-reply Receive SCCRQ, Clean up, idle 2549 lose tie-breaker Re-queue SCCRQ 2550 for idle state 2552 wait-ctl-reply Receive SCCCN Send StopCCN idle 2553 Clean up 2555 wait-ctl-conn Receive SCCCN, Send tunnel-open established 2556 acceptable event to waiting 2557 sessions 2559 wait-ctl-conn Receive SCCCN, Send StopCCN, idle 2560 not acceptable Clean up 2562 wait-ctl-conn Receive SCCRP, Send StopCCN, idle 2563 SCCRQ Clean up 2565 established Local Send tunnel-open established 2566 Open request event to waiting 2567 (new call) sessions 2569 established Admin Send StopCCN idle 2570 Tunnel Close Clean up 2572 established Receive SCCRQ, Send StopCCN idle 2573 SCCRP, SCCCN Clean up 2575 idle Receive StopCCN Clean up idle 2576 wait-ctl-reply, 2577 wait-ctl-conn, 2578 established 2579 The states associated with the LNS or LAC for control connection 2580 establishment are: 2582 idle 2583 Both initiator and recipient start from this state. An initiator 2584 transmits an SCCRQ, while a recipient remains in the idle state 2585 until receiving an SCCRQ. 2587 wait-ctl-reply 2588 The originator checks to see if another connection has been 2589 requested from the same peer, and if so, handles the collision 2590 situation described in Section 5.8. 2592 When an SCCRP is received, it is examined for a compatible 2593 version. If the version of the reply is lower than the version 2594 sent in the request, the older (lower) version should be used 2595 provided it is supported. If the version in the reply is earlier 2596 and supported, the originator moves to the established state. If 2597 the version is earlier and not supported, a StopCCN MUST be sent 2598 to the peer and the originator cleans up and terminates the 2599 tunnel. 2601 wait-ctl-conn 2602 This is where an SCCCN is awaited; upon receipt, the challenge 2603 response is checked. The tunnel either is established, or is torn 2604 down if an authorization failure is detected. 2606 established 2607 An established connection may be terminated by either a local 2608 condition or the receipt of a Stop-Control-Connection- 2609 Notification. In the event of a local termination, the originator 2610 MUST send a Stop-Control-Connection-Notification and clean up the 2611 tunnel. 2613 If the originator receives a Stop-Control-Connection-Notification 2614 it MUST also clean up the tunnel. 2616 7.3 Timing considerations 2618 Due to the real-time nature of telephone signaling, both the LNS and 2619 LAC should be implemented with multi-threaded architectures such that 2620 messages related to multiple calls are not serialized and blocked. 2621 The call and connection state figures do not specify exceptions 2622 caused by timers. These are addressed in Section 5.8. 2624 7.4 Incoming calls 2626 An Incoming-Call-Request message is generated by the LAC when an 2627 incoming call is detected (for example, an associated telephone line 2628 rings). The LAC selects a Session ID and serial number and indicates 2629 the call bearer type. Modems should always indicate analog call type. 2630 ISDN calls should indicate digital when unrestricted digital service 2631 or rate adaption is used and analog if digital modems are involved. 2632 Calling Number, Called Number, and Subaddress may be included in the 2633 message if they are available from the telephone network. 2635 Once the LAC sends the Incoming-Call-Request, it waits for a response 2636 from the LNS but it does not necessarily answer the call from the 2637 telephone network yet. The LNS may choose not to accept the call if: 2639 - No resources are available to handle more sessions 2640 - The dialed, dialing, or subaddress fields do not correspond to 2641 an authorized user 2642 - The bearer service is not authorized or supported 2644 If the LNS chooses to accept the call, it responds with an Incoming- 2645 Call-Reply. When the LAC receives the Incoming-Call-Reply, it 2646 attempts to connect the call. A final call connected message from 2647 the LAC to the LNS indicates that the call states for both the LAC 2648 and the LNS should enter the established state. If the call 2649 terminated before the LNS could accept it, a Call-Disconnect-Notify 2650 is sent by the LAC to indicate this condition. 2652 When the dialed-in client hangs up, the call is cleared normally and 2653 the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to 2654 clear a call, it sends a Call-Disconnect-Notify message and cleans up 2655 its session. 2657 7.4.1 LAC Incoming Call States 2659 State Event Action New State 2660 ----- ----- ------ --------- 2661 idle Bearer Ring or Initiate local wait-tunnel 2662 Ready to indicate tunnel open 2663 incoming conn. 2665 idle Receive ICCN, Clean up idle 2666 ICRP, CDN 2668 wait-tunnel Bearer line drop Clean up idle 2669 or local close 2670 request 2672 wait-reply Local Clean up idle 2673 close request or 2674 Bearer line drop 2676 wait-tunnel tunnel-open Send ICRQ wait-reply 2678 wait-reply Receive ICRP, Send ICCN established 2679 acceptable 2681 wait-reply Receive ICRP, Send CDN, idle 2682 Not acceptable Clean up 2684 wait-reply Receive ICRQ Send CDN idle 2685 Clean up 2687 wait-reply Receive CDN Clean up idle 2688 ICCN 2690 wait-reply Local Send CDN, idle 2691 close request or Clean up 2692 Bearer line drop 2694 established Receive CDN Clean up idle 2696 established Receive ICRQ, Send CDN, idle 2697 ICRP, ICCN Clean up 2699 established Bearer line Send CDN, idle 2700 drop or local Clean up 2701 close request 2703 The states associated with the LAC for incoming calls are: 2705 idle 2706 The LAC detects an incoming call on one of its interfaces. 2707 Typically this means an analog line is ringing or an ISDN TE has 2708 detected an incoming Q.931 SETUP message. The LAC initiates its 2709 tunnel establishment state machine, and moves to a state waiting 2710 for confirmation of the existence of a tunnel. 2712 wait-tunnel 2713 In this state the session is waiting for either the control 2714 connection to be opened or for verification that the tunnel is 2715 already open. Once an indication that the tunnel has/was opened, 2716 session control messages may be exchanged. The first of these is 2717 the Incoming-Call-Request. 2719 wait-reply 2720 The LAC receives either a CDN message indicating the LNS is not 2721 willing to accept the call (general error or don't accept) and 2722 moves back into the idle state, or an Incoming-Call-Reply message 2723 indicating the call is accepted, the LAC sends an Incoming-Call- 2724 Connected message and enters the established state. 2726 established 2727 Data is exchanged over the tunnel. The call may be cleared 2728 following: 2729 + An event on the connected interface: The LAC sends a Call- 2730 Disconnect-Notify message 2731 + Receipt of a Call-disconnect-Notify message: The LAC cleans 2732 up, disconnecting the call. 2733 + A local reason: The LAC sends a Call-Disconnect-Notify 2734 message. 2736 7.4.2 LNS Incoming Call States 2738 State Event Action New State 2739 ----- ----- ------ --------- 2740 idle Receive ICRQ, Send ICRP wait-connect 2741 acceptable 2743 idle Receive ICRQ, Send CDN, idle 2744 not acceptable Clean up 2746 idle Receive ICRP Send CDN idle 2747 Clean up 2749 idle Receive ICCN Clean up idle 2751 wait-connect Receive ICCN Prepare for established 2752 acceptable data 2754 wait-connect Receive ICCN Send CDN, idle 2755 not acceptable Clean up 2757 wait-connect Receive ICRQ, Send CDN idle 2758 ICRP Clean up 2760 idle, Receive CDN Clean up idle 2761 wait-connect, 2762 established 2764 wait-connect Local Send CDN, idle 2765 established Close request Clean up 2767 established Receive ICRQ, Send CDN idle 2768 ICRP, ICCN Clean up 2770 The states associated with the LNS for incoming calls are: 2772 idle 2773 An Incoming-Call-Request message is received. If the request is 2774 not acceptable, a Call-Disconnect-Notify is sent back to the LAC 2775 and the LNS remains in the idle state. If the Incoming-Call- 2776 Request message is acceptable, an Incoming-Call-Reply is sent. The 2777 session moves to the wait-connect state. 2779 wait-connect 2780 If the session is still connected on the LAC, the LAC sends an 2781 Incoming-Call-Connected message to the LNS which then moves into 2782 established state. The LAC may send a Call-Disconnect-Notify to 2783 indicate that the incoming caller could not be connected. This 2784 could happen, for example, if a telephone user accidentally places 2785 a standard voice call to an LAC resulting in a handshake failure 2786 on the called modem. 2788 established 2789 The session is terminated either by receipt of a Call-Disconnect- 2790 Notify message from the LAC or by sending a Call-Disconnect- 2791 Notify. Clean up follows on both sides regardless of the 2792 initiator. 2794 7.5 Outgoing calls 2796 Outgoing calls are initiated by an LNS and instruct an LAC to place a 2797 call. There are three messages for outgoing calls: Outgoing-Call- 2798 Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS 2799 sends an Outgoing-Call-Request specifying the dialed party phone 2800 number, subaddress and other parameters. The LAC MUST respond to the 2801 Outgoing-Call-Request message with an Outgoing-Call-Reply message 2802 once the LAC determines that the proper facilities exist to place the 2803 call and the call is administratively authorized. For example, is 2804 this LNS allowed to dial an international call? Once the outbound 2805 call is connected, the LAC sends an Outgoing-Call-Connected message 2806 to the LNS indicating the final result of the call attempt: 2808 7.5.1 LAC Outgoing Call States 2810 State Event Action New State 2811 ----- ----- ------ --------- 2812 idle Receive OCRQ, Send OCRP, wait-cs-answer 2813 acceptable Open bearer 2815 idle Receive OCRQ, Send CDN, idle 2816 not acceptable Clean up 2818 idle Receive OCRP Send CDN idle 2819 Clean up 2821 idle Receive OCCN, Clean up idle 2822 CDN 2824 wait-cs-answer Bearer answer, Send OCCN established 2825 framing detected 2827 wait-cs-answer Bearer failure Send CDN, idle 2828 Clean up 2830 wait-cs-answer Receive OCRQ, Send CDN idle 2831 OCRP, OCCN Clean up 2833 established Receive OCRQ, Send CDN idle 2834 OCRP, OCCN Clean up 2836 wait-cs-answer, Receive CDN Clean up idle 2837 established 2839 established Bearer line drop, Send CDN, idle 2840 Local close Clean up 2841 request 2843 The states associated with the LAC for outgoing calls are: 2845 idle 2846 If Outgoing-Call-Request is received in error, respond with a 2847 Call-Disconnect-Notify. Otherwise, allocate a physical channel and 2848 send an Outgoing-Call-Reply. Place the outbound call and move to 2849 the wait-cs-answer state. 2851 wait-cs-answer 2852 If the call is not completed or a timer expires waiting for the 2853 call to complete, send a Call-Disconnect-Notify with the 2854 appropriate error condition set and go to idle state. If a circuit 2855 switched connection is established and framing is detected, send 2856 an Outgoing-Call-Connected indicating success and go to 2857 established state. 2859 established 2860 If a Call-Disconnect-Notify is received by the LAC, the telco call 2861 MUST be released via appropriate mechanisms and the session 2862 cleaned up. If the call is disconnected by the client or the 2863 called interface, a Call-Disconnect-Notify message MUST be sent to 2864 the LNS. The sender of the Call-Disconnect-Notify message returns 2865 to the idle state after sending of the message is complete. 2867 7.5.2 LNS Outgoing Call States 2869 State Event Action New State 2870 ----- ----- ------ --------- 2871 idle Local Initiate local wait-tunnel 2872 open request tunnel-open 2874 idle Receive OCCN, Clean up idle 2875 OCRP, CDN 2877 wait-tunnel tunnel-open Send OCRQ wait-reply 2879 wait-reply Receive OCRP, none wait-connect 2880 acceptable 2882 wait-reply Receive OCRP, Send CDN idle 2883 not acceptable Clean up 2885 wait-reply Receive OCCN, Send CDN idle 2886 OCRQ Clean up 2888 wait-connect Receive OCCN none established 2890 wait-connect Receive OCRQ, Send CDN idle 2891 OCRP Clean up 2893 idle, Receive CDN, Clean up idle 2894 wait-reply, 2895 wait-connect, 2896 established 2898 established Receive OCRQ, Send CDN idle 2899 OCRP, OCCN Clean up 2901 wait-reply, Local Send CDN idle 2902 wait-connect, Close request Clean up 2903 established 2905 wait-tunnel Local Clean up idle 2906 Close request 2908 The states associated with the LNS for outgoing calls are: 2910 idle, wait-tunnel 2911 When an outgoing call is initiated, a tunnel is first created, 2912 much as the idle and wait-tunnel states for an LAC incoming call. 2914 Once a tunnel is established, an Outgoing-Call-Request message is 2915 sent to the LAC and the session moves into the wait-reply state. 2917 wait-reply 2918 If a Call-Disconnect-Notify is received, an error occurred, and 2919 the session is cleaned up and returns to idle. If an Outgoing- 2920 Call-Reply is received, the call is in progress and the session 2921 moves to the wait-connect state. 2923 wait-connect 2924 If a Call-Disconnect-Notify is received, the call failed; the 2925 session is cleaned up and returns to idle. If an Outgoing-Call- 2926 Connected is received, the call has succeeded and the session may 2927 now exchange data. 2929 established 2930 If a Call-Disconnect-Notify is received, the call has been 2931 terminated for the reason indicated in the Result and Cause Codes; 2932 the session moves back to the idle state. If the LNS chooses to 2933 terminate the session, it sends a Call-Disconnect-Notify to the 2934 LAC and then cleans up and idles its session. 2936 7.6 Tunnel Disconnection 2938 The disconnection of a tunnel consists of either peer issuing a 2939 Stop-Control-Connection-Notification. The sender of this Notification 2940 should wait a finite period of time for the acknowledgment of this 2941 message before releasing the control information associated with the 2942 tunnel. The recipient of this Notification should send an 2943 acknowledgment of the Notification and then release the associated 2944 control information. 2946 When to release a tunnel is an implementation issue and is not 2947 specified in this document. A particular implementation may use 2948 whatever policy is appropriate for determining when to release a 2949 control connection. Some implementations may leave a tunnel open for 2950 a period of time or perhaps indefinitely after the last session for 2951 that tunnel is cleared. Others may choose to disconnect the tunnel 2952 immediately after the last user connection on the tunnel disconnects. 2954 8.0 L2TP Over Specific Media 2956 L2TP is self-describing, operating at a level above the media over 2957 which it is carried. However, some details of its connection to media 2958 are required to permit interoperable implementations. The following 2959 sections describe details needed to permit interoperability over 2960 specific media. 2962 8.1 L2TP over UDP/IP 2964 L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP 2965 packet, including payload and L2TP header, is sent within a UDP 2966 datagram. The initiator of an L2TP tunnel picks an available source 2967 UDP port (which may or may not be 1701), and sends to the desired 2968 destination address at port 1701. The recipient picks a free port on 2969 its own system (which may or may not be 1701), and sends its reply to 2970 the initiator's UDP port and address, setting its own source port to 2971 the free port it found. Once the source and destination ports and 2972 addresses are established, they MUST remain static for the life of 2973 the tunnel. 2975 It has been suggested that having the recipient choose an arbitrary 2976 source port (as opposed to using the destination port in the packet 2977 initiating the tunnel, i.e., 1701) may make it more difficult for 2978 L2TP to traverse some NAT devices. Implementors should consider the 2979 potential implication of this before before choosing an arbitrary 2980 source port. 2982 IP fragmentation may occur as the L2TP packet travels over the IP 2983 substrate. L2TP makes no special efforts to optimize this. A LAC 2984 implementation MAY cause its LCP to negotiate for a specific MRU, 2985 which could optimize for LAC environments in which the MTU's of the 2986 path over which the L2TP packets are likely to travel have a 2987 consistent value. 2989 The default for any L2TP implementation is that UDP checksums MUST be 2990 enabled for both control and data messages. An L2TP implementation 2991 MAY provide an option to disable UDP checksums for data messages. It 2992 is recommended that UDP checksums always be enabled on control 2993 packets. 2995 Port 1701 is used for both L2F [RFC2341] and L2TP packets. The 2996 Version field in each header may be used to discriminate between the 2997 two packet types (L2F uses a value of 1, and the L2TP version 2998 described in this document uses a value of 2). An L2TP implementation 2999 running on a system which does not support L2F MUST silently discard 3000 all L2F packets. 3002 To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP link has 3003 the characteristic of being able to reorder or silently drop packets. 3004 The former may break non-IP protocols being carried by PPP, 3005 especially LAN-centric ones such as bridging. The latter may break 3006 protocols which assume per-packet indication of error, such as TCP 3007 header compression. Sequencing may be handled by using L2TP data 3008 message sequence numbers if any protocol being transported by the PPP 3009 tunnel cannot tolerate reordering. The sequence dependency 3010 characteristics of individual protocols are outside the scope of this 3011 document. 3013 Allowing packets to be dropped silently is perhaps more problematic 3014 with some protocols. If PPP reliable delivery [RFC1663] is enabled, 3015 no upper PPP protocol will encounter lost packets. If L2TP sequence 3016 numbers are enabled, L2TP can detect the packet loss. In the case of 3017 an LNS, the PPP and L2TP stacks are both present within the LNS, and 3018 packet loss signaling may occur precisely as if a packet was received 3019 with a CRC error. Where the LAC and PPP stack are co-resident, this 3020 technique also applies. Where the LAC and PPP client are physically 3021 distinct, the analogous signaling MAY be accomplished by sending a 3022 packet with a CRC error to the PPP client. Note that this would 3023 greatly increase the complexity of debugging client line problems, 3024 since the client statistics could not distinguish between true media 3025 errors and LAC-initiated ones. Further, this technique is not 3026 possible on all hardware. 3028 If VJ comprssion is used, and neither PPP reliable delivery nor 3029 sequence numbers are enabled, each lost packet results in a 1 in 3030 2**16 chance of a TCP segment being forwarded with incorrect contents 3031 [RFC1144]. Where the combination of the packet loss rate with this 3032 statistical exposure is unacceptable, TCP header compression SHOULD 3033 NOT be used. 3035 In general, it is wise to remember that the L2TP/UDP/IP transport is 3036 an unreliable transport. As with any PPP media that is subject to 3037 loss, care should be taken when using protocols that are particularly 3038 loss-sensitive. Such protocols include compression and encryption 3039 protocols that employ history. 3041 8.2 IP 3043 When operating in IP environments, L2TP MUST offer the UDP 3044 encapsulation described in 8.1 as its default configuration for IP 3045 operation. Other configurations (perhaps corresponding to a 3046 compressed header format) MAY be defined and made available as a 3047 configurable option. 3049 9.0 Security Considerations 3051 L2TP encounters several security issues in its operation. The 3052 general approach of L2TP to these issues is documented here. 3054 9.1 Tunnel Endpoint Security 3056 The tunnel endpoints may optionally perform an authentication 3057 procedure of one another during tunnel establishment. This 3058 authentication has the same security attributes as CHAP, and has 3059 reasonable protection against replay and snooping during the tunnel 3060 establishment process. This mechanism is not designed to provide any 3061 authentication beyond tunnel establishment; it is fairly simple for a 3062 malicious user who can snoop the tunnel stream to inject packets once 3063 an authenticated tunnel establishment has been completed 3064 successfully. 3066 For authentication to occur, the LAC and LNS MUST share a single 3067 secret. Each side uses this same secret when acting as authenticatee 3068 as well as authenticator. Since a single secret is used, the tunnel 3069 authentication AVPs include differentiating values in the CHAP ID 3070 fields for each message digest calculation to guard against replay 3071 attacks. 3073 The Assigned Tunnel ID and Assigned Session ID (See Section 4.3.3) 3074 SHOULD be selected in an unpredictable manner rather than 3075 sequentially or otherwise. Doing so will help deter hijacking of a 3076 session by a malicious user who does not have access to packet traces 3077 between the LAC and LNS. 3079 9.2 Packet Level Security 3081 Securing L2TP requires that the underlying transport make available 3082 encryption, integrity and authentication services for all L2TP 3083 traffic. This secure transport operates on the entire L2TP packet 3084 and is functionally independent of PPP and the protocol being carried 3085 by PPP. As such, L2TP is only concerned with confidentiality, 3086 wuthenticity, and integrity of the L2TP packets between its tunnel 3087 endpoints (the LAC and LNS), not unlike link-layer encryption being 3088 concerned only about protecting the confidentiality of traffic 3089 between its physical endpoints. 3091 9.3 End to End Security 3093 Protecting the L2TP packet stream via a secure transport does, in 3094 turn, also protect the data within the tunneled PPP packets while 3095 transported from the LAC to the LNS. Such protection should not be 3096 considered a substitution for end-to-end security between 3097 communicating hosts or applications. 3099 9.4 L2TP and IPsec 3101 When running over IP, IPsec provides packet-level security via ESP 3102 and/or AH. All L2TP control and data packets for a particular tunnel 3103 appear as homogeneous UDP/IP data packets to the IPsec system. 3105 In addition to IP transport security, IPsec defines a mode of 3106 operation that allows tunnelling of IP packets. The packet level 3107 encryption and authentication provided by IPsec tunnel mode and that 3108 provided by L2TP secured with IPsec provide an equivalent level of 3109 security for these requirements. 3111 IPsec also defines access control features that are required of a 3112 compliant IPsec implementation. These features allow filtering of 3113 packets based upon network and transport layer characteristics such 3114 as IP address, ports, etc. In the L2TP tunnelling model, analogous 3115 filtering is logically performed at the PPP layer or network layer 3116 above L2TP. These network layer access control features may be 3117 handled at the LNS via vendor-specific authorization features based 3118 upon the authenticated PPP user, or at the network layer itself by 3119 using IPsec transport mode end-to-end between the communicating 3120 hosts. The requirements for access control mechanisms are not a part 3121 of the L2TP specification and as such are outside the scope of this 3122 document. 3124 9.5 Proxy PPP Authentication 3126 L2TP defines AVPs that MAY be exchanged during session establishment 3127 to provide forwarding of PPP authentication information obtained at 3128 the LAC to the LNS for validation (see Section 4.3.5). This implies a 3129 direct trust relationship of the LAC on behalf of the LNS. If the 3130 LNS chooses to implement proxy authentication, it MUST be able to be 3131 configured off, requiring a new round a PPP authentication initiated 3132 by the LNS (which may or may not include a new round of LCP 3133 negotiation). 3135 10.0 IANA Considerations 3137 This document defines a number of "magic" numbers to be maintained by 3138 the IANA. This section explains the criteria to be used by the IANA 3139 to assign additional numbers in each of these lists. The following 3140 subsections describe the assignment policy for the namespaces defined 3141 elsewhere in this document. 3143 10.1 AVP Attributes 3145 As defined in Section 4.1, AVPs contain vendor ID, Attribute and 3146 Value fields. For vendor ID value of 0, IANA will maintain a registry 3147 of assigned Attributes and in some case also values. Attributes 0-39 3148 are assigned as defined in Section 4.3. The remaining values are 3149 available for assignment through IETF Consensus [RFC 2434]. 3151 10.2 Message Type AVP Values 3153 As defined in Section 4.3.1, Message Type AVPs (Attribute Type 0) 3154 have an associated value maintained by IANA. Values 0-16 are defined 3155 in Section 3.2, the remaining values are available for assignment via 3156 IETF Consensus [RFC 2434] 3158 10.3 Result Code AVP Values 3160 As defined in Section 4.3.2, Result Code AVPs (Attribute Type 1) 3161 contain three fields. Two of these fields (the Result Code and Error 3162 Code fields) have associated values maintained by IANA. 3164 10.3.1 Result Code Field Values 3166 The Result Code AVP may be included in CDN and StopCCN messages. The 3167 allowable values for the Result Code field of the AVP differ 3168 depending upon the value of the Message Type AVP. For the StopCCN 3169 message, values 0-7 are defined in Section 4.3.2; for the StopCCN 3170 message, values 0-11 are defined in the same section. The remaining 3171 values of the Result Code field for both messages are available for 3172 assignment via IETF Consensus [RFC 2434]. 3174 10.3.1 Error Code Field Values 3176 Values 0-7 are defined in Section 4.3.2. Values 8-32767 are 3177 available for assignment via IETF Consensus [RFC 2434]. The remaining 3178 values of the Error Code field are available for assignment via First 3179 Come First Served [RFC 2434]. 3181 10.4 Framing Capabilities & Bearer Capabilities 3183 The Framing Capabilities AVP and Bearer Capabilities AVPs (defined in 3184 Section 4.3.3) both contain 32-bit bitmasks. Additional bits should 3185 only be defined via a Standards Action [RFC 2434]. 3187 10.5 Proxy Authen Type AVP Values 3189 The Proxy Authen Type AVP (Attribute Type 29) has an associated value 3190 maintained by IANA. Values 0-5 are defined in Section 4.3.5, the 3191 remaining values are available for assignment via First Come First 3192 Served [RFC 2434]. 3194 10.6 AVP Header Bits 3196 There are four remaining reserved bits in the AVP header. Additional 3197 bits should only be assigned via a Standards Action [RFC 2434]. 3199 11.0 References 3201 [DSS1]ITU-T Recommendation, "Digital subscriber Signaling System No. 1 3202 (DSS 1) - ISDN user-network interface layer 3 specification for 3203 basic call control", Rec. Q.931(I.451), May 1998 3205 [KPS]Kaufman, C., Perlman, R., and Speciner, M., "Network Security: 3206 Private Communications in a Public World", Prentice Hall, March 3207 1995, ISBN 0-13-061466-1 3209 [PPTP]K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn, 3210 "Point-to-Point Tunneling Protocol (PPTP)", ``work in progress'', 3211 October 1998 3213 [RFC791] 3214 Postel, J., Internet Protocol, STD 5, RFC 791, September 1981 3216 [RFC1034] 3217 Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, 3218 RFC 1034, November 1987 3220 [RFC1144] 3221 Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial 3222 Links", RFC 1144, February 1990 3224 [RFC1661] 3225 Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 3226 July 1994 3228 [RFC1662] 3229 Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 3230 1994 3232 [RFC1663] 3233 Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994 3235 [RFC1700] 3236 Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 3237 October 1994 3239 [RFC1990] 3240 Sklower, K., et al., "The PPP Multilink Protocol (MP)", RFC 1990, 3241 August 1996 3243 [RFC1994] 3244 Simpson, W., "PPP Challenge Handshake Authentication Protocol 3245 (CHAP)", RFC 1994, August 1996 3247 [RFC1918] 3248 Rekhter, Y., et al., Address Allocation for Private Internets, BCP 3249 5, RFC 1918, February 1996 3251 [RFC2119] 3252 Bradner, S., "Key words for use in RFCs to Indicate Requirement 3253 Levels", BCP 14, RFC 2119, March 1997 3255 [RFC2138] 3256 Rigney, C., et al., "Remote Authentication Dial In User Service 3257 (RADIUS)", RFC 2138, April 1997 3259 [RFC2277] 3260 Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 3261 18, RFC 2277, January 1998 3263 [RFC2341] 3264 Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two Forward- 3265 ing (Protocol) L2F", RFC 2341, May 1998 3267 [RFC2434] 3268 Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Con- 3269 siderations Section in RFCs", BCP 26, RFC 2434, October 1998 3271 [RFC2401] 3272 Kent, S., Atkinson, R., "Security Architecture for the Internet 3273 Protocol", RFC 2401, November 1998 3275 [STEVENS] 3276 Stevens, W. Richard, "TCP/IP Illustrated, Volume I The Protocols", 3277 Addison-Wesley Publishing Company, Inc., March 1996, ISBN 3278 0-201-63346-9 3280 12.0 Acknowledgments 3282 The basic concept for L2TP and many of its protocol constructs were 3283 adopted from L2F [RFC2341] and PPTP [PPTP]. Authors of these are A. 3284 Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein, 3285 J. Taarud, W. Little, and G. Zorn. 3287 Dory Leifer made valuable refinements to the protocol definition of 3288 L2TP and contributed to the editing of this document. 3290 Steve Cobb and Evan Caves redesigned the state machine tables. 3292 Barney Wolff provided a great deal of design input on the endpoint 3293 authentication mechanism. 3295 John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, 3296 Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and 3297 review at the 43rd IETF in Orlando, FL., which led to improvement of 3298 the overall readability and clarity of this document. 3300 13.0 Author's Addresses 3302 Gurdeep Singh Pall 3303 Microsoft Corporation 3304 Redmond, WA 3305 gurdeep@microsoft.com 3307 Bill Palter 3308 RedBack Networks, Inc 3309 1389 Moffett Park Drive 3310 Sunnyvale, CA 94089 3311 palter@zev.net 3313 Allan Rubens 3314 Ascend Communications 3315 1701 Harbor Bay Parkway 3316 Alameda, CA 94502 3317 acr@del.com 3319 W. Mark Townsley 3320 cisco Systems 3321 7025 Kit Creek Road 3322 PO Box 14987 3323 Research Triangle Park, NC 27709 3324 townsley@cisco.com 3326 Andrew J. Valencia 3327 cisco Systems 3328 170 West Tasman Drive 3329 San Jose CA 95134-1706 3330 vandys@cisco.com 3332 Glen Zorn 3333 Microsoft Corporation 3334 One Microsoft Way 3335 Redmond, WA 98052 3336 gwz@acm.org 3338 Appendix A: Control Channel Slow Start and Congestion Avoidance 3340 Although each side has indicated the maximum size of its receive win- 3341 dow, it is recommended that a slow start and congestion avoidance 3342 method be used to transmit control packets. The methods described 3343 here are based upon the TCP congestion avoidance algorithm as 3344 described in section 21.6 of TCP/IP Illustrated, Volume I, by W. 3345 Richard Stevens [STEVENS]. 3347 Slow start and congestion avoidance make use of several variables. 3348 The congestion window (CWND) defines the number of packets a sender 3349 may send before waiting for an acknowledgment. The size of CWND 3350 expands and contracts as described below. Note however, that CWND is 3351 never allowed to exceed the size of the advertised window obtained 3352 from the Receive Window AVP (in the text below, it is assumed any 3353 increase will be limited by the Receive Window Size). The variable 3354 SSTHRESH determines when the sender switches from slow start to 3355 congestion avoidance. Slow start is used while CWND is less than 3356 SSHTRESH. 3358 A sender starts out in the slow start phase. CWND is initialized to 3359 one packet, and SSHTRESH is initialized to the advertised window 3360 (obtained from the Receive Window AVP). The sender then transmits 3361 one packet and waits for its acknowledgement (either explicit or pig- 3362 gybacked). When the acknowledgement is received, the congestion win- 3363 dow is incremented from one to two. During slow start, CWND is 3364 increased by one packet each time an ACK (explicit ZLB or pig- 3365 gybacked) is received. Increasing CWND by one on each ACK has the 3366 effect of doubling CWND with each round trip, resulting in an 3367 exponential increase. When the value of CWND reaches SSHTRESH, the 3368 slow start phase ends and the congestion avoidance phase begins. 3370 During congestion avoidance, CWND expands more slowly. Specifically, 3371 it increases by 1/CWND for every new ACK received. That is, CWND is 3372 increased by one packet after CWND new ACKs have been received. Win- 3373 dow expansion during the congestion avoidance phase is effectively 3374 linear, with CWND increasing by one packet each round trip. 3376 When congestion occurs (indicated by the triggering of a retransmis- 3377 sion) one half of the CWND is saved in SSTHRESH, and CWND is set to 3378 one. The sender then reenters the slow start phase. 3380 Appendix B: Control Message Examples 3382 B.1: Lock-step tunnel establishment 3384 In this example, an LAC establishes a tunnel, with the exchange 3385 involving each side alternating in sending messages. This example 3386 is contrived, in that the final acknowledgment in the example is 3387 explicitly sent within a zero-length message, although most typi- 3388 cally the acknowledgment would have been included in the process- 3389 ing of the Incoming-Call-Request which had prompted the LAC to 3390 initiate the tunnel in the first place. 3392 LAC or LNS LNS or LAC 3393 ---------- ---------- 3395 SCCRQ -> 3396 Nr: 0, Ns: 0 3397 <- SCCRP 3398 Nr: 1, Ns: 0 3399 SCCCN -> 3400 Nr: 1, Ns: 1 3401 <- ZLB 3402 Nr: 2, Ns: 1 3404 B.2: Lost packet with retransmission 3406 An existing tunnel has a new session requested by the LAC. The ICRP 3407 is lost and must be retransmitted by the LNS. Note that loss of the 3408 ICRP has two impacts: not only does it keep the upper level state 3409 machine from progressing, but it also keeps the LAC from seeing a 3410 timely lower level acknowledgment of its ICRQ. 3412 LAC LNS 3413 --- --- 3415 ICRQ -> 3416 Nr: 1, Ns: 2 3418 (packet lost) <- ICRP 3419 Nr: 3, Ns: 1 3421 (pause; LAC's timer started first, so fires first) 3423 ICRQ -> 3424 Nr: 1, Ns: 2 3426 (LNS realizes it has already seen this 3427 packet and discards it.) 3429 (LNS's timer fires.) 3431 <- ICRP 3432 Nr: 3, Ns: 1 3433 ICCN -> 3434 Nr: 2, Ns: 3 3436 <- ZLB 3437 Nr: 4, Ns: 2 3439 Appendix C: Intellectual Property Notice 3441 The IETF takes no position regarding the validity or scope of any 3442 intellectual property or other rights that might be claimed to per- 3443 tain to the implementation or use of the technology described in this 3444 document or the extent to which any license under such rights might 3445 or might not be available; neither does it represent that it has made 3446 any effort to identify any such rights. Information on the IETF's 3447 procedures with respect to rights in standards-track and standards- 3448 related documentation can be found in BCP-11. Copies of claims of 3449 rights made available for publication and any assurances of licenses 3450 to be made available, or the result of an attempt made to obtain a 3451 general license or permission for the use of such proprietary rights 3452 by implementors or users of this specification can be obtained from 3453 the IETF Secretariat." 3455 The IETF invites any interested party to bring to its attention any 3456 copyrights, patents or patent applications, or other proprietary 3457 rights which may cover technology that may be required to practice 3458 this standard. Please address the information to the IETF Executive 3459 Director. 3461 The IETF has been notified of intellectual property rights claimed in 3462 regard to some or all of the specification contained in this docu- 3463 ment. For more information consult the online list of claimed 3464 rights.