idnits 2.17.1 draft-ietf-l2tpext-l2tpbis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 47 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 77 longer pages, the longest (page 1) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 77 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 17 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC1661]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2786 has weird spacing: '...e local wai...' == Line 2787 has weird spacing: '...ndicate tunne...' == Line 2992 has weird spacing: '...e local wai...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The framing capabilities defined in this AVP refer only to the physical interfaces available for dialout usage on an LAC. An LNS MUST not send an OCRQ with a Framing Type AVP specifying a value not advertised in this AVP. Presence of this message is not a guarantee that a given outgoing call will be placed by the sender if requested, just that the physical capability exists. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The framing capabilitiies defined in this AVP refer only to the physical interfaces available for dialout usage on an LAC. An LNS MUST not send an OCRQ with a Bearer Type AVP specifying a value not advertised in this AVP. -- 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 (November 2000) is 8563 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 349, but not defined == Missing Reference: 'System' is mentioned on line 349, but not defined == Missing Reference: 'Remote' is mentioned on line 1919, but not defined == Missing Reference: 'RFC 2434' is mentioned on line 3315, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'RFC791' is defined on line 3328, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 3356, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 3373, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 3376, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS1' -- Possible downref: Non-RFC (?) normative reference: ref. 'KPS' ** 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 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2637 -- Possible downref: Non-RFC (?) normative reference: ref. 'STEVENS' Summary: 12 errors (**), 0 flaws (~~), 17 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W. Townsley 2 Internet-Draft A. Valencia 3 Category: Standards Track G. Zorn 4 cisco Systems 5 A. Rubens 6 Tut Systems 7 G. Pall 8 Microsoft Corporation 9 B. Palter 10 Redback Networks 11 November 2000 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 May 31, 2001. Please send 43 comments to the L2TP mailing list (l2tp@l2tp.net). 45 Copyright Notice 47 Copyright (C) The Internet Society (1999). All Rights Reserved. 49 Abstract 51 This document describes the Layer Two Tunneling Protocol (L2TP). RFC 52 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP 53 facilitates the tunneling of PPP packets across an intervening 54 network in a way that is as transparent as possible to both end-users 55 and applications. 57 Contents 59 Status of this Memo.......................................... 1 60 1.0 Introduction.......................................... 4 61 1.1 Specification of Requirements......................... 5 62 1.2 Terminology........................................... 5 63 2.0 Topology.............................................. 8 64 3.0 Protocol Overview..................................... 9 65 3.1 L2TP Header Format.................................... 10 66 3.2 Control Message Types................................. 12 67 4.0 Control Message Attribute Value Pairs................. 13 68 4.1 AVP Format............................................ 13 69 4.2 Mandatory AVPs........................................ 15 70 4.3 Hiding of AVP Attribute Values........................ 15 71 4.4 AVP Summary........................................... 17 72 5.0 Protocol Operation.................................... 42 73 5.1 Control Connection Establishment...................... 42 74 5.2 Session Establishment................................. 43 75 5.3 Forwarding PPP Frames................................. 44 76 5.4 Using Sequence Numbers on the Data Channel............ 45 77 5.5 Keepalive (Hello)..................................... 45 78 5.6 Session Teardown...................................... 46 79 5.7 Control Connection Teardown........................... 46 80 5.8 Reliable Delivery of Control Messages................. 47 81 6.0 Control Connection Protocol Specification............. 49 82 6.1 Start-Control-Connection-Request (SCCRQ).............. 49 83 6.2 Start-Control-Connection-Reply (SCCRP)................ 49 84 6.3 Start-Control-Connection-Connected (SCCCN)............ 50 85 6.4 Stop-Control-Connection-Notification (StopCCN)........ 50 86 6.5 Hello (HELLO)......................................... 50 87 6.6 Incoming-Call-Request (ICRQ).......................... 51 88 6.7 Incoming-Call-Reply (ICRP)............................ 52 89 6.8 Incoming-Call-Connected (ICCN)........................ 52 90 6.9 Outgoing-Call-Request (OCRQ).......................... 53 91 6.10 Outgoing-Call-Reply (OCRP)........................... 54 92 6.11 Outgoing-Call-Connected (OCCN)....................... 54 93 6.12 Call-Disconnect-Notify (CDN)......................... 54 94 6.13 WAN-Error-Notify (WEN)............................... 55 95 6.14 Set-Link-Info (SLI).................................. 55 96 7.0 Control Connection State Machines..................... 56 97 7.1 Control Connection Protocol Operation................. 56 98 7.2 Control Connection States............................. 57 99 7.2.1 Control Connection Establishment................. 57 100 7.3 Timing considerations................................. 59 101 7.4 Incoming calls........................................ 59 102 7.4.1 LAC Incoming Call States......................... 60 103 7.4.2 LNS Incoming Call States......................... 62 104 7.5 Outgoing calls........................................ 63 105 7.5.1 LAC Outgoing Call States......................... 63 106 7.5.2 LNS Outgoing Call States......................... 64 107 7.6 Tunnel Disconnection.................................. 66 108 8.0 L2TP Over Specific Media.............................. 66 109 8.1 L2TP over UDP/IP...................................... 66 110 8.2 IP.................................................... 68 111 9.0 Security Considerations............................... 68 112 9.1 Tunnel Endpoint Security.............................. 68 113 9.2 Packet Level Security................................. 69 114 9.3 End to End Security................................... 69 115 9.4 L2TP and IPsec........................................ 69 116 9.5 Proxy PPP Authentication.............................. 70 117 10.0 IANA Considerations.................................. 70 118 10.1 AVP Attributes....................................... 70 119 10.2 Message Type AVP Values.............................. 70 120 10.3 Result Code AVP Values............................... 70 121 10.3.1 Result Code Field Values........................ 71 122 10.3.2 Error Code Field Values......................... 71 123 10.4 Framing Capabilities & Bearer Capabilities........... 71 124 10.5 Proxy Authen Type AVP Values......................... 71 125 10.6 AVP Header Bits...................................... 71 126 11.0 References........................................... 71 127 12.0 Acknowledgments...................................... 73 128 13.0 Authors' Addresses................................... 73 130 Appendix A: Control Channel Slow Start and Congestion Avoidance 74 132 Appendix B: Control Message Examples......................... 75 134 Appendix C: Intellectual Property Notice..................... 76 136 1.0 Introduction 138 The Layer Two Tunneling Protocol (L2TP) provides a mechanism for 139 aggregation of multiple layer two connections across packet oriented 140 data networks. These layer two connections may be PPP [RFC1661] or 141 other layer two connections such as Frame Relay, ATM, etc. This 142 document defines the specific mechanisms for tunneling of PPP, 143 including a control protocol for on-demand creation of tunnels 144 between nodes and the accompanying encapsulation for multiplexing 145 multiple, tunneled, PPP sessions. The specifics of tunneling layer 2 146 links other than PPP with L2TP will be defined separately. 148 PPP defines an encapsulation mechanism for transporting multiprotocol 149 packets across layer 2 (L2) point-to-point links. Typically, a user 150 obtains a L2 connection to a Network Access Server (NAS) using one of 151 a number of techniques (e.g., dialup POTS, ISDN, ADSL, etc.) and 152 then runs PPP over that connection. In such a configuration, the L2 153 termination point and PPP session endpoint reside on the same 154 physical device (i.e., the NAS). 156 L2TP extends the PPP model by allowing the L2 and PPP endpoints to 157 reside on different devices interconnected by a packet-switched 158 network. With L2TP, a user has an L2 connection to an access 159 concentrator (e.g., modem bank, ADSL DSLAM, etc.), and the 160 concentrator then tunnels individual PPP frames to the NAS. This 161 allows the actual processing of PPP packets to be divorced from the 162 termination of the L2 circuit. 164 One obvious benefit of such a separation is that instead of requiring 165 the L2 connection terminate at the NAS (which may require a long- 166 distance toll charge), the connection may terminate at a (local) 167 circuit concentrator, which then extends the logical PPP session over 168 a shared infrastructure such as a frame relay circuit or the 169 Internet. From the user's perspective, there is no functional 170 difference between having the L2 circuit terminate in a NAS directly 171 or using L2TP. 173 L2TP may also solve the multilink hunt-group splitting problem. 174 Multilink PPP [RFC1990] requires that all channels composing a 175 multilink bundle be grouped at a single Network Access Server (NAS). 176 Due to its ability to project a PPP session to a location other than 177 the point at which it was physically received, L2TP can be used to 178 make all channels terminate at a single NAS. This allows multilink 179 operation even when the calls are spread across distinct physical 180 NASs. 182 1.1 Specification of Requirements 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 1.2 Terminology 190 Analog Channel 192 A circuit-switched communication path which is intended to carry 193 3.1 kHz audio in each direction. 195 Attribute Value Pair (AVP) 197 The variable length concatenation of a unique Attribute 198 (represented by an integer) and a Value containing the actual 199 value identified by the attribute. Multiple AVPs make up Control 200 Messages which are used in the establishment, maintenance, and 201 teardown of tunnels. 203 Call 205 A connection (or attempted connection) between a Remote System and 206 LAC. For example, a telephone call through the PSTN. A Call 207 (Incoming or Outgoing) which is successfully established between a 208 Remote System and LAC results in a corresponding L2TP Session 209 within a previously established Tunnel between the LAC and LNS. 210 (See also: Session, Incoming Call, Outgoing Call). 212 Called Number 214 An indication to the receiver of a call as to what telephone 215 number the caller used to reach it. 217 Calling Number 219 An indication to the receiver of a call as to the telephone number 220 of the caller. 222 CHAP 224 Challenge Handshake Authentication Protocol [RFC1994], a PPP 225 cryptographic challenge/response authentication protocol in which 226 the cleartext password is not passed over the line. 228 Control Connection 230 A control connection operates in-band over a tunnel to control the 231 establishment, release, and maintenance of sessions and of the 232 tunnel itself. 234 Control Messages 236 Control messages are exchanged between LAC and LNS pairs, 237 operating in-band within the tunnel protocol. Control messages 238 govern aspects of the tunnel and sessions within the tunnel. 240 Digital Channel 242 A circuit-switched communication path which is intended to carry 243 digital information in each direction. 245 DSLAM 247 Digital Subscriber Line (DSL) Access Module. A network device used 248 in the deployment of DSL service. This is typically a concentrator 249 of individual DSL lines located in a central office (CO) or local 250 exchange. 252 Incoming Call 254 A Call received at an LAC to be tunneled to an LNS (see Call, 255 Outgoing Call). 257 L2TP Access Concentrator (LAC) 259 A node that acts as one side of an L2TP tunnel endpoint and is a 260 peer to the L2TP Network Server (LNS). The LAC sits between an LNS 261 and a remote system and forwards packets to and from each. Packets 262 sent from the LAC to the LNS requires tunneling with the L2TP 263 protocol as defined in this document. The connection from the LAC 264 to the remote system is either local (see: Client LAC) or a PPP 265 link. 267 L2TP Network Server (LNS) 269 A node that acts as one side of an L2TP tunnel endpoint and is a 270 peer to the L2TP Access Concentrator (LAC). The LNS is the logical 271 termination point of a PPP session that is being tunneled from the 272 remote system by the LAC. 274 Management Domain (MD) 276 A network or networks under the control of a single 277 administration, policy or system. For example, an LNS's Management 278 Domain might be the corporate network it serves. An LAC's 279 Management Domain might be the Internet Service Provider that owns 280 and manages it. 282 Network Access Server (NAS) 284 A device providing local network access to users across a remote 285 access network such as the PSTN. An NAS may also serve as an LAC, 286 LNS or both. 288 Outgoing Call 290 A Call placed by an LAC on behalf of an LNS (see Call, Incoming 291 Call). 293 Peer 295 When used in context with L2TP, peer refers to either the LAC or 296 LNS. An LAC's Peer is an LNS and vice versa. When used in context 297 with PPP, a peer is either side of the PPP connection. 299 POTS 301 Plain Old Telephone Service. 303 Remote System 305 An end-system or router attached to a remote access network (i.e. 306 a PSTN), which is either the initiator or recipient of a call. 307 Also referred to as a dial-up or virtual dial-up client. 309 Session 311 L2TP is connection-oriented. The LNS and LAC maintain state for 312 each Call that is initiated or answered by an LAC. An L2TP Session 313 is created between the LAC and LNS when an end-to-end PPP 314 connection is established between a Remote System and the LNS. 315 Datagrams related to the PPP connection are sent over the Tunnel 316 between the LAC and LNS. There is a one to one relationship 317 between established L2TP Sessions and their associated Calls. (See 318 also: Call). 320 Tunnel 322 A Tunnel exists between a LAC-LNS pair. The Tunnel consists of a 323 Control Connection and zero or more L2TP Sessions. The Tunnel 324 carries encapsulated PPP datagrams and Control Messages between 325 the LAC and the LNS. 327 Zero-Length Body (ZLB) Message 329 A control packet with only an L2TP header. ZLB messages are used 330 for explicitly acknowledging packets on the reliable control 331 channel. 333 2.0 Topology 335 The following diagram depicts a typical L2TP scenario. The goal is to 336 tunnel PPP frames between the Remote System or LAC Client and an LNS 337 located at a Home LAN. 339 [Home LAN] 340 [LAC Client]----------+ | 341 ____|_____ +--[Host] 342 | | | 343 [LAC]---------| Internet |-----[LNS]-----+ 344 | |__________| | 345 _____|_____ : 346 | | 347 | PSTN | 348 [Remote]--| Cloud | 349 [System] | | [Home LAN] 350 |___________| | 351 | ______________ +---[Host] 352 | | | | 353 [LAC]-------| Frame Relay |---[LNS]-----+ 354 | or ATM Cloud | | 355 |______________| : 357 The Remote System initiates a PPP connection across the PSTN Cloud to 358 an LAC. The LAC then tunnels the PPP connection across the Internet, 359 Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN is 360 obtained. The Remote System is provided addresses from the HOME LAN 361 via PPP NCP negotiation. Authentication, Authorization and Accounting 362 may be provided by the Home LAN's Management Domain as if the user 363 were connected to a Network Access Server directly. 365 A LAC Client (a Host which runs L2TP natively) may also participate 366 in tunneling to the Home LAN without use of a separate LAC. In this 367 case, the Host containing the LAC Client software already has a 368 connection to the public Internet. A "virtual" PPP connection is then 369 created and the local L2TP LAC Client software creates a tunnel to 370 the LNS. As in the above case, Addressing, Authentication, 371 Authorization and Accounting will be provided by the Home LAN's 372 Management Domain. 374 3.0 Protocol Overview 376 L2TP utilizes two types of messages, control messages and data 377 messages. Control messages are used in the establishment, maintenance 378 and clearing of tunnels and calls. Data messages are used to 379 encapsulate PPP frames being carried over the tunnel. Control 380 messages utilize a reliable Control Channel within L2TP to guarantee 381 delivery (see section 5.1 for details). Data messages are not 382 retransmitted when packet loss occurs. 384 +-------------------+ 385 | PPP Frames | 386 +-------------------+ +-----------------------+ 387 | L2TP Data Messages| | L2TP Control Messages | 388 +-------------------+ +-----------------------+ 389 | L2TP Data Channel | | L2TP Control Channel | 390 | (unreliable) | | (reliable) | 391 +------------------------------------------------+ 392 | Packet Transport (UDP, FR, ATM, etc.) | 393 +------------------------------------------------+ 395 Figure 3.0 L2TP Protocol Structure 397 Figure 3.0 depicts the relationship of PPP frames and Control 398 Messages over the L2TP Control and Data Channels. PPP Frames are 399 passed over an unreliable Data Channel encapsulated first by an L2TP 400 header and then a Packet Transport such as UDP, Frame Relay, ATM, 401 etc. Control messages are sent over a reliable L2TP Control Channel 402 which transmits packets in-band over the same Packet Transport. 404 Sequence numbers are required to be present in all control messages 405 and are used to provide reliable delivery on the Control Channel. 406 Data Messages may use sequence numbers to reorder packets and detect 407 lost packets. 409 All values are placed into their respective fields and sent in 410 network order (high order octets first). 412 3.1 L2TP Header Format 414 L2TP packets for the control channel and data channel share a common 415 header format. In each case where a field is optional, its space does 416 not exist in the message if the field is marked not present. Note 417 that while optional on data messages, the Length, Ns, and Nr fields 418 marked as optional below, are required to be present on all control 419 messages. 421 This header is formatted: 423 0 1 2 3 424 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Tunnel ID | Session ID | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Ns (opt) | Nr (opt) | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Offset Size (opt) | Offset pad... (opt) 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 Figure 3.1 L2TP Message Header 437 The Type (T) bit indicates the type of message. It is set to 0 for a 438 data message and 1 for a control message. 440 If the Length (L) bit is 1, the Length field is present. This bit 441 MUST be set to 1 for control messages. 443 The x bits are reserved for future extensions. All reserved bits MUST 444 be set to 0 on outgoing messages and ignored on incoming messages. 446 If the Sequence (S) bit is set to 1 the Ns and Nr fields are present. 447 The S bit MUST be set to 1 for control messages. 449 If the Offset (O) bit is 1, the Offset Size field is present. The O 450 bit MUST be set to 0 (zero) for control messages. 452 If the Priority (P) bit is 1, this data message should receive 453 preferential treatment in its local queuing and transmission. LCP 454 echo requests used as a keepalive for the link, for instance, should 455 generally be sent with this bit set to 1. Without it, a temporary 456 interval of local congestion could result in interference with 457 keepalive messages and unnecessary loss of the link. This feature is 458 only for use with data messages. The P bit MUST be set to 0 for all 459 control messages. 461 Ver MUST be 2, indicating the version of the L2TP data message header 462 described in this document. The value 1 is reserved to permit 463 detection of L2F [RFC2341] packets should they arrive intermixed with 464 L2TP packets. Packets received with an unknown Ver field MUST be 465 discarded. 467 The Length field indicates the total length of the message in octets. 469 Tunnel ID indicates the identifier for the control connection. L2TP 470 tunnels are named by identifiers that have local significance only. 472 That is, the same tunnel will be given different Tunnel IDs by each 473 end of the tunnel. Tunnel ID in each message is that of the intended 474 recipient, not the sender. Tunnel IDs are selected and exchanged as 475 Assigned Tunnel ID AVPs during the creation of a tunnel. 477 Session ID indicates the identifier for a session within a tunnel. 478 L2TP sessions are named by identifiers that have local significance 479 only. That is, the same session will be given different Session IDs 480 by each end of the session. Session ID in each message is that of the 481 intended recipient, not the sender. Session IDs are selected and 482 exchanged as Assigned Session ID AVPs during the creation of a 483 session. 485 Ns indicates the sequence number for this data or control message, 486 beginning at zero and incrementing by one (modulo 2**16) for each 487 message sent. See section 5.8 and 5.4 for more information on using 488 this field. 490 Nr indicates the sequence number expected in the next control message 491 to be received. Thus, Nr is set to the Ns of the last in-order 492 message received plus one (modulo 2**16). In data messages, Nr is 493 reserved and, if present (as indicated by the S-bit), MUST be ignored 494 upon receipt. See section 5.8 for more information on using this 495 field in control messages. 497 The Offset Size field specifies the number of octets past the L2TP 498 header at which the payload data is expected to start. If the offset 499 field is present, the L2TP header ends after the last octet of the 500 offset padding. The offset field itself is considered part of the 501 l2tp header, not part of the offset padding. Thus, an offset field 502 with a value of zero will add two octets to the header length. 503 Actual data within the offset padding is undefined. A recommended 504 maximum for the offset value is 7, which allows for 8 octet 505 alignment. 507 3.2 Control Message Types 509 The Message Type AVP (see section 4.4.1) defines the specific type of 510 control message being sent. Recall from section 3.1 that this is only 511 for control messages, that is, messages with the T-bit set to 1. 513 This document defines the following control message types (see 514 section 6.1 through 6.14 for details on the construction and use of 515 each message): 517 Control Connection Management 518 0 (reserved) 520 1 (SCCRQ) Start-Control-Connection-Request 521 2 (SCCRP) Start-Control-Connection-Reply 522 3 (SCCCN) Start-Control-Connection-Connected 523 4 (StopCCN) Stop-Control-Connection-Notification 524 5 (reserved) 525 6 (HELLO) Hello 527 Call Management 529 7 (OCRQ) Outgoing-Call-Request 530 8 (OCRP) Outgoing-Call-Reply 531 9 (OCCN) Outgoing-Call-Connected 532 10 (ICRQ) Incoming-Call-Request 533 11 (ICRP) Incoming-Call-Reply 534 12 (ICCN) Incoming-Call-Connected 535 13 (reserved) 536 14 (CDN) Call-Disconnect-Notify 538 Error Reporting 540 15 (WEN) WAN-Error-Notify 542 PPP Session Control 544 16 (SLI) Set-Link-Info 546 4.0 Control Message Attribute Value Pairs 548 To maximize extensibility while still permitting interoperability, a 549 uniform method for encoding message types and bodies is used 550 throughout L2TP. This encoding will be termed AVP (Attribute-Value 551 Pair) in the remainder of this document. 553 4.1 AVP Format 555 Each AVP is encoded as: 557 0 1 2 3 558 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 |M|H| rsvd | Length | Vendor ID | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Attribute Type | Attribute Value... 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 [until Length is reached]... | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 The first six bits are a bit mask, describing the general attributes 567 of the AVP. 569 Two bits are defined in this document, the remaining are reserved for 570 future extensions. Reserved bits MUST be set to 0. An AVP received 571 with a reserved bit set to 1 MUST be treated as an unrecognized AVP. 573 Mandatory (M) bit: Controls the behavior required of an 574 implementation which receives an AVP which it does not recognize. If 575 the M bit is set on an unrecognized AVP within a message associated 576 with a particular session, the session associated with this message 577 MUST be terminated. If the M bit is set on an unrecognized AVP within 578 a message associated with the overall tunnel, the entire tunnel (and 579 all sessions within) MUST be terminated. If the M bit is not set, an 580 unrecognized AVP MUST be ignored. The control message must then 581 continue to be processed as if the AVP had not been present. 583 Hidden (H) bit: Identifies the hiding of data in the Attribute Value 584 field of an AVP. This capability can be used to avoid the passing of 585 sensitive data, such as user passwords, as cleartext in an AVP. 586 section 4.3 describes the procedure for performing AVP hiding. 588 Length: Encodes the number of octets (including the Overall Length 589 and bitmask fields) contained in this AVP. The Length may be 590 calculated as 6 + the length of the Attribute Value field in octets. 591 The field itself is 10 bits, permitting a maximum of 1023 octets of 592 data in a single AVP. The minimum Length of an AVP is 6. If the 593 length is 6, then the Attribute Value field is absent. 595 Vendor ID: The IANA assigned "SMI Network Management Private 596 Enterprise Codes" [RFC1700] value. The value 0, corresponding to 597 IETF adopted attribute values, is used for all AVPs defined within 598 this document. Any vendor wishing to implement their own L2TP 599 extensions can use their own Vendor ID along with private Attribute 600 values, guaranteeing that they will not collide with any other 601 vendor's extensions, nor with future IETF extensions. Note that there 602 are 16 bits allocated for the Vendor ID, thus limiting this feature 603 to the first 65,535 enterprises. 605 Attribute Type: A 2 octet value with a unique interpretation across 606 all AVPs defined under a given Vendor ID. 608 Attribute Value: This is the actual value as indicated by the Vendor 609 ID and Attribute Type. It follows immediately after the Attribute 610 Type field, and runs for the remaining octets indicated in the Length 611 (i.e., Length minus 6 octets of header). This field is absent if the 612 Length is 6. 614 4.2 Mandatory AVPs 616 Receipt of an unknown AVP that has the M-bit set is catastrophic to 617 the session or tunnel it is associated with. Thus, the M bit should 618 only be defined for AVPs which are absolutely crucial to proper 619 operation of the session or tunnel. Further, in the case where the 620 LAC or LNS receives an unknown AVP with the M-bit set and shuts down 621 the session or tunnel accordingly, it is the full responsibility of 622 the peer sending the Mandatory AVP to accept fault for causing an 623 non-interoperable situation. Before defining an AVP with the M-bit 624 set, particularly a vendor-specific AVP, be sure that this is the 625 intended consequence. 627 When an adequate alternative exists to use of the M-bit, it should be 628 utilized. For example, rather than simply sending an AVP with the M- 629 bit set to determine if a specific extension exists, availability may 630 be identified by sending an AVP in a request message and expecting a 631 corresponding AVP in a reply message. 633 Use of the M-bit with new AVPs (those not defined in this document) 634 MUST provide the ability to configure the associated feature off, 635 such that the AVP is either not sent, or sent with the M-bit not set. 637 4.3 Hiding of AVP Attribute Values 639 The H bit in the header of each AVP provides a mechanism to indicate 640 to the receiving peer whether the contents of the AVP are hidden or 641 present in cleartext. This feature can be used to hide sensitive 642 control message data such as user passwords or user IDs. 644 The H bit MUST only be set if a shared secret exists between the LAC 645 and LNS and tunnel authentication has completed. The shared secret is 646 the same secret that is used for tunnel authentication (see section 647 5.1.1). Hidden values MUST NOT be unhidden until after tunnel 648 authentication has completed successfully (perhaps requiring the 649 hidden value to be stored until after receipt of additional setup 650 messages). To do otherwise runs the risk of AVP data being utilized 651 without verifying the integrity of the shared secret. If the H bit is 652 set in any AVP(s) in a given control message, a Random Vector AVP 653 must also be present in the message and MUST precede the first AVP 654 having an H bit of 1. 656 Hiding an AVP value is done in several steps. The first step is to 657 take the length and value fields of the original (cleartext) AVP and 658 encode them into a Hidden AVP Subformat as follows: 660 0 1 2 3 661 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Length of Original Value | Original Attribute Value ... 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 ... | Padding ... 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 Length of Original Attribute Value: This is length of the Original 669 Attribute Value to be obscured in octets. This is necessary to 670 determine the original length of the Attribute Value which is lost 671 when the additional Padding is added. 673 Original Attribute Value: Attribute Value that is to be obscured. 675 Padding: Random additional octets used to obscure length of the 676 Attribute Value that is being hidden. 678 To mask the size of the data being hidden, the resulting subformat 679 MAY be padded as shown above. Padding does NOT alter the value placed 680 in the Length of Original Attribute Value field, but does alter the 681 length of the resultant AVP that is being created. For example, If an 682 Attribute Value to be hidden is 4 octets in length, the unhidden AVP 683 length would be 10 octets (6 + Attribute Value length). After hiding, 684 the length of the AVP will become 6 + Attribute Value length + size 685 of the Length of Original Attribute Value field + Padding. Thus, if 686 Padding is 12 octets, the AVP length will be 6 + 4 + 2 + 12 = 24 687 octets. 689 Next, An MD5 hash is performed on the concatenation of: 691 + the 2 octet Attribute number of the AVP 692 + the shared secret 693 + an arbitrary length random vector 695 The value of the random vector used in this hash is passed in the 696 value field of a Random Vector AVP. This Random Vector AVP must be 697 placed in the message by the sender before any hidden AVPs. The same 698 random vector may be used for more than one hidden AVP in the same 699 message. If a different random vector is used for the hiding of 700 subsequent AVPs then a new Random Vector AVP must be placed in the 701 command message before the first AVP to which it applies. 703 The MD5 hash value is then XORed with the first 16 octet (or less) 704 segment of the Hidden AVP Subformat and placed in the Attribute Value 705 field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 706 octets, the Subformat is transformed as if the Attribute Value field 707 had been padded to 16 octets before the XOR, but only the actual 708 octets present in the Subformat are modified, and the length of the 709 AVP is not altered. 711 If the Subformat is longer than 16 octets, a second one-way MD5 hash 712 is calculated over a stream of octets consisting of the shared secret 713 followed by the result of the first XOR. That hash is XORed with the 714 second 16 octet (or less) segment of the Subformat and placed in the 715 corresponding octets of the Value field of the Hidden AVP. 717 If necessary, this operation is repeated, with the shared secret used 718 along with each XOR result to generate the next hash to XOR the next 719 segment of the value with. 721 The hiding method was adapted from RFC 2138 [RFC2138] which was taken 722 from the "Mixing in the Plaintext" section in the book "Network 723 Security" by Kaufman, Perlman and Speciner [KPS]. A detailed 724 explanation of the method follows: 726 Call the shared secret S, the Random Vector RV, and the Attribute 727 Value AV. Break the value field into 16-octet chunks p1, p2, etc. 728 with the last one padded at the end with random data to a 16-octet 729 boundary. Call the ciphertext blocks c(1), c(2), etc. We will also 730 define intermediate values b1, b2, etc. 732 b1 = MD5(AV + S + RV) c(1) = p1 xor b1 733 b2 = MD5(S + c(1)) c(2) = p2 xor b2 734 . . 735 . . 736 . . 737 bi = MD5(S + c(i-1)) c(i) = pi xor bi 739 The String will contain c(1)+c(2)+...+c(i) where + denotes 740 concatenation. 742 On receipt, the random vector is taken from the last Random Vector 743 AVP encountered in the message prior to the AVP to be unhidden. The 744 above process is then reversed to yield the original value. 746 4.4 AVP Summary 748 The following sections contain a list of all L2TP AVPs defined in 749 this document. 751 Following the name of the AVP is a list indicating the message types 752 that utilize each AVP. After each AVP title follows a short 753 description of the purpose of the AVP, a detail (including a graphic) 754 of the format for the Attribute Value, and any additional information 755 needed for proper use of the AVP. 757 4.4.1 AVPs Applicable To All Control Messages 759 Message Type (All Messages) 761 The Message Type AVP, Attribute Type 0, identifies the control 762 message herein and defines the context in which the exact meaning 763 of the following AVPs will be determined. 765 The Attribute Value field for this AVP has the following format: 767 0 1 768 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Message Type | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 The Message Type is a 2 octet unsigned integer. 775 The Message Type AVP MUST be the first AVP in a message, 776 immediately following the control message header (defined in 777 section 3.1). See section 3.2 for the list of defined control 778 message types and their identifiers. 780 The Mandatory (M) bit within the Message Type AVP has special 781 meaning. Rather than an indication as to whether the AVP itself 782 should be ignored if not recognized, it is an indication as to 783 whether the control message itself should be ignored. Thus, if the 784 M-bit is set within the Message Type AVP and the Message Type is 785 unknown to the implementation, the tunnel MUST be cleared. If the 786 M-bit is not set, then the implementation may ignore an unknown 787 message type. The M-bit MUST be set to 1 for all message types 788 defined in this document. This AVP may not be hidden (the H-bit 789 MUST be 0). The Length of this AVP is 8. 791 A Vendor Specific control message may be defined by setting the 792 Vendor ID of the Message Type AVP to a value other than the IETF 793 Vendor ID of 0 (see section 4.1). 795 Random Vector (All Messages) 797 The Random Vector AVP, Attribute Type 36, is used to enable the 798 hiding of the Attribute Value of arbitrary AVPs. 800 The Attribute Value field for this AVP has the following format: 802 0 1 2 3 803 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Random Octet String ... 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 The Random Octet String may be of arbitrary length, although a 809 random vector of at least 16 octets is recommended. The string 810 contains the random vector for use in computing the MD5 hash to 811 retrieve or hide the Attribute Value of a hidden AVP (see section 812 4.3). 814 More than one Random Vector AVP may appear in a message, in which 815 case a hidden AVP uses the Random Vector AVP most closely 816 preceding it. This AVP MUST precede the first AVP with the H bit 817 set. 819 The M-bit for this AVP MUST be set to 1. This AVP MUST NOT be 820 hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the 821 length of the Random Octet String. 823 4.4.2 Result and Error Codes 825 Result Code (CDN, StopCCN) 827 The Result Code AVP, Attribute Type 1, indicates the reason for 828 terminating the control channel or session. 830 The Attribute Value field for this AVP has the following format: 832 0 1 2 3 833 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Result Code | Error Code (opt) | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Error Message (opt) ... 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 The Result Code is a 2 octet unsigned integer. The optional Error 841 Code is a 2 octet unsigned integer. An optional Error Message can 842 follow the Error Code field. Presence of the Error Code and 843 Message are indicated by the AVP Length field. The Error Message 844 contains an arbitrary string providing further (human readable) 845 text associated with the condition. Human readable text in all 846 error messages MUST be provided in the UTF-8 charset using the 847 Default Language [RFC2277]. 849 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 850 this AVP MUST be set to 1. The Length is 8 if there is no Error 851 Code or Message, 10 if there is an Error Code and no Error Message 852 or 10 + the length of the Error Message if there is an Error Code 853 and Message. 855 Defined Result Code values for the StopCCN message are: 857 0 - Reserved 858 1 - General request to clear control connection 859 2 - General error, Error Code indicates the problem 860 3 - Control channel already exists 861 4 - Requester is not authorized to establish a control channel 862 5 - The protocol version of the requester is not supported, 863 Error Code indicates highest version supported 864 6 - Requester is being shut down 865 7 - Finite State Machine error 867 Defined Result Code values for the CDN message are: 869 0 - Reserved 870 1 - Call disconnected due to loss of carrier 871 2 - Call disconnected for the reason indicated 872 in Error Code 873 3 - Call disconnected for administrative reasons 874 4 - Call failed due to lack of appropriate facilities being 875 available (temporary condition) 876 5 - Call failed due to lack of appropriate facilities being 877 available (permanent condition) 878 6 - Invalid destination 879 7 - Call failed due to no carrier detected 880 8 - Call failed due to detection of a busy signal 881 9 - Call failed due to lack of a dial tone 882 10 - Call was not established within time allotted 883 11 - Call was connected but no appropriate framing was detected 885 The Error Codes defined below pertain to types of errors that are 886 not specific to any particular L2TP request, but rather to 887 protocol or message format errors. If an L2TP reply indicates in 888 its Result Code that a general error occurred, the General Error 889 value should be examined to determine what the error was. The 890 currently defined General Error codes and their meanings are: 892 0 - No general error 893 1 - No control connection exists yet for this LAC-LNS pair 894 2 - Length is wrong 895 3 - One of the field values was out of range or 896 reserved field was non-zero 897 4 - Insufficient resources to handle this operation now 898 5 - The Session ID is invalid in this context 899 6 - A generic vendor-specific error occurred 900 7 - Try another. If initiator is aware of other possible responder 901 destinations, it should try one of them. This can be 902 used to guide an LAC or LNS based on policy, for instance, 903 the existence of multilink PPP bundles at an LNS. 904 8 - The session or tunnel was shutdown due to receipt of an unknown 905 AVP with the M-bit set (see section 4.2). The Error Message 906 SHOULD contain the attribute of the offending AVP in (human 907 readable) text form. 908 9 - Try another directed. If an LAC or LNS is aware of other possible 909 destinations, it should inform the initiator of the tunnel or 910 session. The Error Message MUST contain a comma separated list 911 of addresses for the initiator to choose from. If the L2TP 912 transport is IPv4, then this would be a comma separated list 913 of IP addresses in the canonical dotted-decimal format. i.e. 914 "10.0.0.1, 10.0.0.2, 10.0.0.3" If there are no servers for 915 the LAC or LNS to suggest, then Error Code 7 should be used. 916 The delimiter between addresses MUST be precisely a single 917 comma and a single space. 919 When a General Error Code of 6 is used, additional information 920 about the error SHOULD be included in the Error Message field. 921 Further, a vendor specific AVP MAY be sent to indicate the problem 922 more precisely. 924 4.4.3 Control Connection Management AVPs 926 Protocol Version (SCCRP, SCCRQ) 928 The Protocol Version AVP, Attribute Type 2, indicates the L2TP 929 protocol version of the sender. 931 The Attribute Value field for this AVP has the following format: 933 0 1 934 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Ver | Rev | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 The Ver field is a 1 octet unsigned integer containing the value 940 1. Rev field is a 1 octet unsigned integer containing 0. This 941 pertains to L2TP protocol version 1, revision 0. Note this is not 942 the same version number that is included in the header of each 943 message. 945 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 946 this AVP MUST be set to 1. The Length of this AVP is 8. 948 Framing Capabilities (SCCRP, SCCRQ) 950 The Framing Capabilities AVP, Attribute Type 3, provides the peer 951 with an indication of the types of framing that will be accepted 952 or requested by the sender. 954 The Attribute Value field for this AVP has the following format: 956 0 1 2 3 957 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Reserved for future framing type definitions |A|S| 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 The Attribute Value field is a 32-bit mask, with two bits defined. 963 If bit A is set, asynchronous framing is supported. If bit S is 964 set, synchronous framing is supported. 966 The framing capabilities defined in this AVP refer only to the 967 physical interfaces available for dialout usage on an LAC. An LNS 968 MUST not send an OCRQ with a Framing Type AVP specifying a value 969 not advertised in this AVP. Presence of this message is not a 970 guarantee that a given outgoing call will be placed by the sender 971 if requested, just that the physical capability exists. 973 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 974 this AVP MUST be set to 1. The Length (before hiding) is 10. 976 Bearer Capabilities (SCCRP, SCCRQ) 978 The Bearer Capabilities AVP, Attribute Type 4, provides the peer 979 with an indication of the bearer device types supported by the 980 hardware interfaces of the sender for outgoing calls. 982 The Attribute Value field for this AVP has the following format: 984 0 1 2 3 985 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Reserved for future bearer type definitions |V|A|D| 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 This is a 32-bit mask, with two bits defined. If bit A is set, 991 analog access is supported. If bit D is set, digital access is 992 supported. Bit V is set, virtual access is supported. Virtual 993 access refers to access where there is no physical point to point 994 link. 996 The framing capabilitiies defined in this AVP refer only to the 997 physical interfaces available for dialout usage on an LAC. An LNS 998 MUST not send an OCRQ with a Bearer Type AVP specifying a value 999 not advertised in this AVP. 1001 This AVP MUST be present if the sender can place outgoing calls 1002 when requested. Presence of this message is not a guarantee that a 1003 given outgoing call will be placed by the sender if requested, 1004 just that the physical capability exists. 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 1. The Length (before hiding) is 10. 1009 Tie Breaker (SCCRQ) 1011 The Tie Breaker AVP, Attribute Type 5, indicates that the sender 1012 wishes a single tunnel to exist between the given LAC-LNS pair. 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 | Tie Break Value... 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 ...(64 bits) | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 The Tie Breaker Value is an 8 octet value that is used to choose a 1025 single tunnel where both LAC and LNS request a tunnel 1026 concurrently. The recipient of a SCCRQ must check to see if a 1027 SCCRQ has been sent to the peer, and if so, must compare its Tie 1028 Breaker value with the received one. The lower value "wins", and 1029 the "loser" MUST silently discard its tunnel. In the case where a 1030 tie breaker is present on both sides, and the value is equal, both 1031 sides MUST discard their tunnels. 1033 If a tie breaker is received, and an outstanding SCCRQ had no tie 1034 breaker value, the initiator which included the Tie Breaker AVP 1035 "wins". If neither side issues a tie breaker, then two separate 1036 tunnels are opened. 1038 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1039 this AVP MUST be set to 0. The Length of this AVP is 14. 1041 Firmware Revision (SCCRP, SCCRQ) 1042 The Firmware Revision AVP, Attribute Type 6, indicates the 1043 firmware revision of the issuing device. 1045 The Attribute Value field for this AVP has the following format: 1047 0 1 1048 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | Firmware Revision | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 The Firmware Revision is a 2 octet unsigned integer encoded in a 1054 vendor specific format. 1056 For devices which do not have a firmware revision (general purpose 1057 computers running L2TP software modules, for instance), the 1058 revision of the L2TP software module may be reported instead. 1060 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1061 this AVP MUST be set to 0. The Length (before hiding) is 8. 1063 Host Name (SCCRP, SCCRQ) 1065 The Host Name AVP, Attribute Type 7, indicates the name of the 1066 issuing LAC or LNS. 1068 The Attribute Value field for this AVP has the following format: 1070 0 1 2 3 1071 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Host Name ... (arbitrary number of octets) 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 The Host Name is of arbitrary length, but MUST be at least 1 1077 octet. 1079 This name should be as broadly unique as possible; for hosts 1080 participating in DNS [RFC1034], a hostname with fully qualified 1081 domain would be appropriate. The Host Name MAY be used to identify 1082 tunnel configuration, including the shared secret for tunnel 1083 authentication (if enabled) and any other options defined for the 1084 tunnel. 1086 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1087 this AVP MUST be set to 1. The Length of this AVP is 6 plus the 1088 length of the Host Name. 1090 Vendor Name (SCCRP, SCCRQ) 1092 The Vendor Name AVP, Attribute Type 8, contains a vendor specific 1093 (possibly human readable) string describing the type of LAC or LNS 1094 being used. 1096 The Attribute Value field for this AVP has the following format: 1098 0 1 2 3 1099 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Vendor Name ...(arbitrary number of octets) 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 The Vendor Name is the indicated number of octets representing the 1105 vendor string. Human readable text for this AVP MUST be provided 1106 in the UTF-8 charset using the Default Language [RFC2277]. 1108 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1109 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1110 is 6 plus the length of the Vendor Name. 1112 Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN) 1114 The Assigned Tunnel ID AVP, Attribute Type 9, encodes the ID being 1115 assigned to this tunnel by the sender. 1117 The Attribute Value field for this AVP has the following format: 1119 0 1 1120 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Assigned Tunnel ID | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 The Assigned Tunnel ID is a 2 octet non-zero unsigned integer. 1127 The Assigned Tunnel ID AVP establishes a value used to multiplex 1128 and demultiplex multiple tunnels between the LNS and LAC. The L2TP 1129 peer MUST place this value in the Tunnel ID header field of all 1130 control and data messages that it subsequently transmits over the 1131 associated tunnel. Before the Assigned Tunnel ID AVP is received 1132 from a peer, messages MUST be sent to that peer with a Tunnel ID 1133 value of 0 in the header of all control messages. 1135 In the StopCCN control message, the Assigned Tunnel ID AVP MUST be 1136 the same as the Assigned Tunnel ID AVP first sent to the receiving 1137 peer, permitting the peer to identify the appropriate tunnel even 1138 if a StopCCN is sent before an Assigned Tunnel ID AVP is received. 1139 If an Assigned Tunnel ID AVP has not been sent in a previous 1140 message, a tunnel ID SHOULD be allocated and sent via the Assigned 1141 Tunnel ID AVP so that the StopCCN may be reliably delivered. This 1142 is most important if the StopCCN carries an essential directive 1143 within, for instance, a Result Code of value 9 with an alternate 1144 address to attempt connecting to. If an Assigned Tunnel ID AVP is 1145 not sent in the StopCCN or any previous message, the StopCCN MUST 1146 NOT be retransmitted. 1148 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1149 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1150 is 8. 1152 Receive Window Size (SCCRQ, SCCRP) 1154 The Receive Window Size AVP, Attribute Type 10, specifies the 1155 receive window size being offered to the remote peer. 1157 The Attribute Value field for this AVP has the following format: 1159 0 1 1160 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | Window Size | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 The Window Size is a 2 octet unsigned integer. 1167 If absent, the peer must assume a Window Size of 4 for its 1168 transmit window. The remote peer may send the specified number of 1169 control messages before it must wait for an acknowledgment. 1171 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1172 this AVP MUST be set to 1. The Length of this AVP is 8. 1174 Challenge (SCCRP, SCCRQ) 1176 The Challenge AVP, Attribute Type 11, indicates that the issuing 1177 peer wishes to authenticate the tunnel endpoints using a CHAP- 1178 style authentication mechanism. 1180 The Attribute Value field for this AVP has the following format: 1182 0 1 2 3 1183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Challenge ... (arbitrary number of octets) 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 The Challenge is one or more octets of random data. 1190 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1191 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1192 is 6 plus the length of the Challenge. 1194 Challenge Response (SCCCN, SCCRP) 1196 The Response AVP, Attribute Type 13, provides a response to a 1197 challenge received. 1199 The Attribute Value field for this AVP has the following format: 1201 0 1 2 3 1202 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | Response ... 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 ... (16 octets) | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 The Response is a 16 octet value reflecting the CHAP-style 1214 [RFC1994] response to the challenge. 1216 This AVP MUST be present in an SCCRP or SCCCN if a challenge was 1217 received in the preceding SCCRQ or SCCRP. For purposes of the ID 1218 value in the CHAP response calculation, the value of the Message 1219 Type AVP for this message is used (e.g. 2 for an SCCRP, and 3 for 1220 an SCCCN). 1222 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1223 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1224 is 22. 1226 4.4.4 Call Management AVPs 1228 Q.931 Cause Code (CDN) 1229 The Q.931 Cause Code AVP, Attribute Type 12, is used to give 1230 additional information in case of unsolicited call disconnection. 1232 The Attribute Value field for this AVP has the following format: 1234 0 1 2 3 1235 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | Cause Code | Cause Msg | Advisory Msg... 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 Cause Code is the returned Q.931 Cause code, and Cause Msg is the 1241 returned Q.931 message code (e.g., DISCONNECT) associated with the 1242 Cause Code. Both values are returned in their native ITU 1243 encodings [DSS1]. An additional ASCII text Advisory Message may 1244 also be included (presence indicated by the AVP Length) to further 1245 explain the reason for disconnecting. 1247 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1248 this AVP MUST be set to 1. The Length of this AVP is 9, plus the 1249 size of the Advisory Message. 1251 Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ) 1253 The Assigned Session ID AVP, Attribute Type 14, encodes the ID 1254 being assigned to this session by the sender. 1256 The Attribute Value field for this AVP has the following format: 1258 0 1 1259 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Assigned Session ID | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 The Assigned Session ID is a 2 octet non-zero unsigned integer. 1266 The Assigned Session ID AVP is establishes a value used to 1267 multiplex and demultiplex data sent over a tunnel between the LNS 1268 and LAC. The L2TP peer MUST place this value in the Session ID 1269 header field of all control and data messages that it subsequently 1270 transmits over the tunnel that belong to this session. Before the 1271 Assigned Session ID AVP is received from a peer, messages MUST be 1272 sent to that peer with a Session ID of 0 in the header of all 1273 control messages. 1275 If an Assigned Session ID AVP has been sent in a previous message, 1276 it MUST be sent in a CDN as well to permit a peer to identify the 1277 appropriate session even if CDN is sent before an Assigned Session 1278 ID is received. If the CDN is sent before an Assigned Session ID 1279 is communicated (e.g. in response to an ICRQ), it MUST NOT be sent 1280 in the CDN message. 1282 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1283 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1284 is 8. 1286 Call Serial Number (ICRQ, OCRQ) 1288 The Call Serial Number AVP, Attribute Type 15, encodes an 1289 identifier assigned by the LAC or LNS to this call. 1291 The Attribute Value field for this AVP has the following format: 1293 0 1 2 3 1294 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | Call Serial Number | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 The Call Serial Number is a 32 bit value. 1301 The Call Serial Number is intended to be an easy reference for 1302 administrators on both ends of a tunnel to use when investigating 1303 call failure problems. Call Serial Numbers should be set to 1304 progressively increasing values, which are likely to be unique for 1305 a significant period of time across all interconnected LNSs and 1306 LACs. 1308 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1309 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1310 is 10. 1312 Minimum BPS (OCRQ) 1314 The Minimum BPS AVP, Attribute Type 16, encodes the lowest 1315 acceptable line speed for this call. 1317 The Attribute Value field for this AVP has the following format: 1319 0 1 2 3 1320 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | Minimum BPS | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 The Minimum BPS is a 32 bit value indicates the speed in bits per 1325 second. 1327 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1328 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1329 is 10. 1331 Maximum BPS (OCRQ) 1333 The Maximum BPS AVP, Attribute Type 17, encodes the highest 1334 acceptable line speed for this call. 1336 The Attribute Value field for this AVP has the following format: 1338 0 1 2 3 1339 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Maximum BPS | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 The Maximum BPS is a 32 bit value indicates the speed in bits per 1345 second. 1347 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1348 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1349 is 10. 1351 Bearer Type (ICRQ, OCRQ) 1353 The Bearer Type AVP, Attribute Type 18, encodes the bearer type 1354 for the incoming or outgoing call. 1356 The Attribute Value field for this AVP has the following format: 1358 0 1 2 3 1359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | Reserved for future Bearer Types |V|A|D| 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 The Bearer Type is a 32-bit bit mask indicating the bearer 1365 capability of the call (ICRQ) or required for the call (OCRQ). Bit 1366 A refers to an analog channel. Bit D refers to a digital channel. 1367 Bit V (virtual) refers to a channel for which there is no physical 1368 point to point link. 1370 Bits set in the Bearer Type AVP in an OCRQ message indicate which 1371 bearer type(s) an outgoing call may be placed on. If more than 1372 one bit is set, the LAC may choose which bearer type to place the 1373 call on. If no bits are set, any type of available channel may be 1374 used. 1376 Bits in the Value field of this AVP MUST only be set by the LNS 1377 for an OCRQ if the same bit was set in the Bearer Capabilities AVP 1378 received from the LAC during control connection establishment. 1380 Bits set in the Bearer Type AVP in an ICRQ message indicate what 1381 bearer type an incoming call was received on at the LAC. If no 1382 bits are set in an ICRQ, then it is assumed that the bearer type 1383 was indeterminable. 1385 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1386 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1387 is 10. 1389 Framing Type (ICCN, OCCN, OCRQ) 1391 The Framing Type AVP, Attribute Type 19, encodes the framing type 1392 for the incoming or outgoing call. 1394 The Attribute Value field for this AVP has the following format: 1396 0 1 2 3 1397 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 | Reserved for future Framing Types |A|S| 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 The Framing Type is a 32-bit mask, which indicates the type of PPP 1403 framing requested for an OCRQ, or the type of PPP framing 1404 negotiated for an OCCN or ICCN. 1406 Bit A indicates asynchronous framing. Bit S indicates synchronous 1407 framing. For an OCRQ, both may be set, indicating that the LAC may 1408 decide the type of framing to be used. 1410 For an ICRQ, only one framing type bit may be set. The framing 1411 type SHOULD be used as an indication to PPP on the LNS as to what 1412 link options to use for LCP negotiation [RFC1662]. For example, if 1413 the A bit is not set in the Framing Type AVP in an ICRQ message 1414 and an ACCM LCP option is requested by the PPP client, then the 1415 LNS should try to respond with no bits set in the ACCM mask as the 1416 LAC will likely not perform async mapping on a non-async 1417 interface. Similarly, if the S bit is set, PPP may wish to reject 1418 address field compression and protocol field compression options. 1420 Bits in the Value field of this AVP MUST only be set by the LNS 1421 for an OCRQ if it was set in the Framing Capabilities AVP received 1422 from the LAC during control connection establishment. 1424 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1425 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1426 is 10. 1428 Called Number (ICRQ, OCRQ) 1430 The Called Number AVP, Attribute Type 21, encodes the telephone 1431 number to be called for an OCRQ, and the Called number for an 1432 ICRQ. 1434 The Attribute Value field for this AVP has the following format: 1436 0 1 2 3 1437 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | Called Number... (arbitrary number of octets) | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 The Called Number is an ASCII string. Contact between the 1443 administrator of the LAC and the LNS may be necessary to 1444 coordinate interpretation of the value needed in this AVP. 1446 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1447 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1448 is 6 plus the length of the Called Number. 1450 Calling Number (ICRQ) 1452 The Calling Number AVP, Attribute Type 22, encodes the originating 1453 number for the incoming call. 1455 The Attribute Value field for this AVP has the following format: 1457 0 1 2 3 1458 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | Calling Number... (arbitrary number of octets) | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 Calling Number is an ASCII string. Contact between the 1464 administrator of the LAC and the LNS may be necessary to 1465 coordinate interpretation of the value in this AVP. 1467 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1468 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1469 is 6 plus the length of the Calling Number. 1471 Sub-Address (ICRQ, OCRQ) 1473 The Sub-Address AVP, Attribute Type 23, encodes additional dialing 1474 information. 1476 The Attribute Value field for this AVP has the following format: 1478 0 1 2 3 1479 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 | Sub-Address ... (arbitrary number of octets) | 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 The Sub-Address is an ASCII string. Contact between the 1485 administrator of the LAC and the LNS may be necessary to 1486 coordinate interpretation of the value in this AVP. 1488 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1489 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1490 is 6 plus the length of the Sub-Address. 1492 (Tx) Connect Speed (ICCN, OCCN) 1494 The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes the 1495 speed of the facility chosen for the connection attempt. 1497 The Attribute Value field for this AVP has the following format: 1499 0 1 2 3 1500 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | BPS | 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 The (Tx) Connect Speed BPS is a 4 octet value indicating the speed 1506 in bits per second. A value of zero indicates that the speed is 1507 indeterminable, or there is no physical point to point link. 1509 When the optional Rx Connect Speed AVP is present, the value in 1510 this AVP represents the transmit connect speed, from the 1511 perspective of the LAC (e.g. data flowing from the LAC to the 1512 remote system). When the optional Rx Connect Speed AVP is NOT 1513 present, the connection speed between the remote system and LAC is 1514 assumed to be symmetric and is represented by the single value in 1515 this AVP. 1517 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1518 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1519 is 10. 1521 Rx Connect Speed (ICCN, OCCN) 1523 The Rx Connect Speed AVP, Attribute Type 38, represents the speed 1524 of the connection from the perspective of the LAC (e.g. data 1525 flowing from the remote system to the LAC). 1527 The Attribute Value field for this AVP has the following format: 1529 0 1 2 3 1530 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | BPS (H) | BPS (L) | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 BPS is a 4 octet value indicating the speed in bits per second. A 1536 value of zero indicates that the speed is indeterminable, or there 1537 is no physical point to point link. 1539 Presence of this AVP implies that the connection speed may be 1540 asymmetric with respect to the transmit connect speed given in the 1541 (Tx) Connect Speed AVP. 1543 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for 1544 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1545 is 10. 1547 Physical Channel ID (ICRQ, OCRP) 1549 The Physical Channel ID AVP, Attribute Type 25, encodes the vendor 1550 specific physical channel number used for a call. 1552 The Attribute Value field for this AVP has the following format: 1554 0 1 2 3 1555 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | Physical Channel ID | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 Physical Channel ID is a 4 octet value intended to be used for 1561 logging purposes only. 1563 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1564 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1565 is 10. 1567 Private Group ID (ICCN) 1569 The Private Group ID AVP, Attribute Type 37, is used by the LAC to 1570 indicate that this call is to be associated with a particular 1571 customer group. 1573 The Attribute Value field for this AVP has the following format: 1575 0 1 2 3 1576 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | Private Group ID ... (arbitrary number of octets) | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 The Private Group ID is a string of octets of arbitrary length. 1583 The LNS MAY treat the PPP session as well as network traffic 1584 through this session in a special manner determined by the peer. 1585 For example, if the LNS is individually connected to several 1586 private networks using unregistered addresses, this AVP may be 1587 included by the LAC to indicate that a given call should be 1588 associated with one of the private networks. 1590 The Private Group ID is a string corresponding to a table in the 1591 LNS that defines the particular characteristics of the selected 1592 group. A LAC MAY determine the Private Group ID from a RADIUS 1593 response, local configuration, or some other source. 1595 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for 1596 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1597 is 6 plus the length of the Private Group ID. 1599 Sequencing Required (ICCN, OCCN) 1601 The Sequencing Required AVP, Attribute Type 39, indicates to the 1602 LNS that Sequence Numbers MUST always be present on the data 1603 channel. 1605 This AVP has no Attribute Value field. 1607 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1608 this AVP MUST be set to 1. The Length of this AVP is 6. 1610 4.4.5 Proxy LCP and Authentication AVPs 1612 The LAC may have answered the call and negotiated LCP with the 1613 remote system, perhaps in order to establish the system's apparent 1614 identity. In this case, these AVPs may be included to indicate the 1615 link properties the remote system initially requested, properties 1616 the remote system and LAC ultimately negotiated, as well as PPP 1617 authentication information sent and received by the LAC. This 1618 information may be used to initiate the PPP LCP and authentication 1619 systems on the LNS, allowing PPP to continue without renegotiation 1620 of LCP. Note that the LNS policy may be to enter an additional 1621 round of LCP negotiation and/or authentication if the LAC is not 1622 trusted. 1624 Initial Received LCP CONFREQ (ICCN) 1626 In the Initial Received LCP CONFREQ AVP, Attribute Type 26, 1627 provides the LNS with the Initial CONFREQ received by the LAC from 1628 the PPP Peer. 1630 The Attribute Value field for this AVP has the following format: 1632 0 1 2 3 1633 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | LCP CONFREQ... (arbitrary number of octets) | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 LCP CONFREQ is a copy of the body of the initial CONFREQ received, 1639 starting at the first option within the body of the LCP message. 1641 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1642 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1643 is 6 plus the length of the CONFREQ. 1645 Last Sent LCP CONFREQ (ICCN) 1647 In the Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the 1648 LNS with the Last CONFREQ sent by the LAC to the PPP Peer. 1650 The Attribute Value field for this AVP has the following format: 1652 0 1 2 3 1653 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 | LCP CONFREQ... (arbitrary number of octets) | 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 The LCP CONFREQ is a copy of the body of the final CONFREQ sent to 1659 the client to complete LCP negotiation, starting at the first 1660 option within the body of the LCP message. 1662 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1663 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1664 is 6 plus the length of the CONFREQ. 1666 Last Received LCP CONFREQ (ICCN) 1668 The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the 1669 LNS with the Last CONFREQ received by the LAC from the PPP Peer. 1671 The Attribute Value field for this AVP has the following format: 1673 0 1 2 3 1674 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 | LCP CONFREQ... (arbitrary number of octets) | 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 The LCP CONFREQ is a copy of the body of the final CONFREQ 1680 received from the client to complete LCP negotiation, starting at 1681 the first option within the body of the LCP message. 1683 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1684 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1685 is 6 plus the length of the CONFREQ. 1687 Proxy Authen Type (ICCN) 1689 The Proxy Authen Type AVP, Attribute Type 29, determines if proxy 1690 authentication should be used. 1692 The Attribute Value field for this AVP has the following format: 1694 0 1 1695 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1697 | Authen Type | 1698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 Authen Type is a 2 octet unsigned integer, holding: 1702 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1703 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1704 is 8. 1706 Defined Authen Type values are: 1707 0 - Reserved 1708 1 - Textual username/password exchange 1709 2 - PPP CHAP 1710 3 - PPP PAP 1711 4 - No Authentication 1712 5 - Microsoft CHAP Version 1 (MSCHAPv1) 1714 This AVP MUST be present if proxy authentication is to be 1715 utilized. If it is not present, then it is assumed that this 1716 peer cannot perform proxy authentication, requiring 1717 a restart of the authentication phase at the LNS if the client 1718 has already entered this phase with the 1719 LAC (which may be determined by the Proxy LCP AVP if present). 1721 Associated AVPs for each type of authentication follow. 1723 Proxy Authen Name (ICCN) 1725 The Proxy Authen Name AVP, Attribute Type 30, specifies the name 1726 of the authenticating client when using proxy authentication. 1728 The Attribute Value field for this AVP has the following format: 1730 0 1 2 3 1731 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 | Authen Name... (arbitrary number of octets) | 1734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 Authen Name is a string of octets of arbitrary length. It 1737 contains the name specified in the client's authentication 1738 response. 1740 This AVP MUST be present in messages containing a Proxy Authen 1741 Type AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable 1742 to employ AVP hiding for obscuring the cleartext name. 1744 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1745 this AVP MUST be set to 0. The Length (before hiding) is 6 plus 1746 the length of the cleartext name. 1748 Proxy Authen Challenge (ICCN) 1750 The Proxy Authen Challenge AVP, Attribute Type 31, specifies the 1751 challenge sent by the LAC to the PPP Peer, when using proxy 1752 authentication. 1754 The Attribute Value field for this AVP has the following format: 1756 0 1 2 3 1757 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 | Challenge... (arbitrary number of octets) | 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 The Challenge is a string of one or more octets. 1764 This AVP MUST be present for Proxy Authen Types 2 and 5. The 1765 Challenge field contains the CHAP challenge presented to the 1766 client by the LAC. 1768 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1769 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1770 is 6, plus the length of the Challenge. 1772 Proxy Authen ID (ICCN) 1774 The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value 1775 of the PPP Authentication that was started between the LAC and the 1776 PPP Peer, when proxy authentication is being used. 1778 The Attribute Value field for this AVP has the following format: 1780 0 1 1781 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 | Reserved | ID | 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 ID is a 2 octet unsigned integer, the most significant octet MUST 1787 be 0. 1789 The Proxy Authen ID AVP MUST be present for Proxy authen types 2, 1790 3 and 5. For 2 and 5, the ID field contains the byte ID value 1791 presented to the client by the LAC in its Challenge. For 3, it is 1792 the Identifier value of the Authenticate-Request. 1794 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1795 this AVP MUST be set to 0. 1797 Proxy Authen Response (ICCN) 1799 The Proxy Authen Response AVP, Attribute Type 33, specifies the 1800 PPP Authentication response received by the LAC from the PPP Peer, 1801 when proxy authentication is used. 1803 The Attribute Value field for this AVP has the following format: 1805 0 1 2 3 1806 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 | Response... (arbitrary number of octets) | 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 The Response is a string of octets. 1813 This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The 1814 Response field contains the client's response to the challenge. 1815 For Proxy authen types 2 and 5, this field contains the response 1816 value received by the LAC. For types 1 or 3, it contains the clear 1817 text password received from the client by the LAC. In the case of 1818 cleartext passwords, AVP hiding is recommended. 1820 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1821 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1822 is 6 plus the length of the Response. 1824 4.4.6 Call Status AVPs 1826 Call Errors (WEN) 1828 The Call Errors AVP, Attribute Type 34, is used by the LAC to send 1829 error information to the LNS. 1831 The Attribute Value field for this AVP has the following format: 1833 0 1 2 3 1834 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 | Reserved | CRC Errors (H) | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | CRC Errors (L) | Framing Errors (H) | 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 | Framing Errors (L) | Hardware Overruns (H) | 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 | Hardware Overruns (L) | Buffer Overruns (H) | 1843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1844 | Buffer Overruns (L) | Time-out Errors (H) | 1845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 | Time-out Errors (L) | Alignment Errors (H) | 1847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1848 | Alignment Errors (L) | 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 The following fields are defined: 1853 Reserved - Not used, MUST be 0 1854 CRC Errors - Number of PPP frames received with CRC errors 1855 since call was established 1856 Framing Errors - Number of improperly framed PPP packets 1857 received 1858 Hardware Overruns - Number of receive buffer over-runs since 1859 call was established 1860 Buffer Overruns - Number of buffer over-runs detected since 1861 call was established 1862 Time-out Errors - Number of time-outs since call was 1863 established 1864 Alignment Errors - Number of alignment errors since call was 1865 established 1867 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1868 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1869 is 32. 1871 ACCM (SLI) 1873 The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC 1874 of the ACCM negotiated with the PPP Peer by the LNS. 1876 The Attribute Value field for this AVP has the following format: 1878 0 1 2 3 1879 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 | Reserved | Send ACCM (H) | 1882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 | Send ACCM (L) | Receive ACCM (H) | 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 | Receive ACCM (L) | 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 Send ACCM and Receive ACCM are each 4 octet values preceded by a 2 1889 octet reserved quantity. The send ACCM value should be used by the 1890 LAC to process packets it sends on the connection. The receive 1891 ACCM value should be used by the LAC to process incoming packets 1892 on the connection. The default values used by the LAC for both 1893 these fields are 0xFFFFFFFF. The LAC should honor these fields 1894 unless it has specific configuration information to indicate that 1895 the requested mask must be modified to permit operation. 1897 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for 1898 this AVP MUST be set to 1. The Length of this AVP is 16. 1900 5.0 Protocol Operation 1902 The necessary setup for tunneling a PPP session with L2TP consists of 1903 two steps, (1) establishing the Control Connection for a Tunnel, and 1904 (2) establishing a Session as triggered by an incoming or outgoing 1905 call request. The Tunnel and corresponding Control Connection MUST be 1906 established before an incoming or outgoing call is initiated. An L2TP 1907 Session MUST be established before L2TP can begin to tunnel PPP 1908 frames. Multiple Sessions may exist across a single Tunnel and 1909 multiple Tunnels may exist between the same LAC and LNS. 1911 +-----+ +-----+ 1912 | |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~| | 1913 | LAC | | LNS | 1914 | #######Control Connection######## | 1915 [Remote] | | | | 1916 [System]------Call----------*============L2TP Session=============* | 1917 PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | 1918 | | | | 1919 [Remote] | | | | 1920 [System]------Call----------*============L2TP Session=============* | 1921 PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | 1922 | | | | 1923 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | 1924 +-----+ +-----+ 1926 Figure 5.1 Tunneling PPP 1928 5.1 Control Connection Establishment 1930 The Control Connection is the initial connection that must be 1931 achieved between an LAC and LNS before sessions may be brought up. 1932 Establishment of the control connection includes securing the 1933 identity of the peer, as well as identifying the peer's L2TP version, 1934 framing, and bearer capabilities, etc. 1936 A three message exchange is utilized to setup the control connection. 1937 Following is a typical message exchange: 1939 LAC or LNS LAC or LNS 1940 ---------- ---------- 1941 SCCRQ -> 1942 <- SCCRP 1943 SCCCN -> 1944 <- ZLB ACK 1946 The ZLB ACK is sent if there are no further messages waiting in queue 1947 for that peer. 1949 5.1.1 Tunnel Authentication 1951 L2TP incorporates a simple, optional, CHAP-like [RFC1994] tunnel 1952 authentication system during control connection establishment. If 1953 an LAC or LNS wishes to authenticate the identity of the peer it 1954 is contacting or being contacted by, a Challenge AVP is included 1955 in the SCCRQ or SCCRP message. If a Challenge AVP is received in 1956 an SCCRQ or SCCRP, a Challenge Response AVP MUST be sent in the 1957 following SCCRP or SCCCN, respectively. If the expected response 1958 and response received from a peer does not match, establishment of 1959 the tunnel MUST be disallowed. 1961 To participate in tunnel authentication, a single shared secret 1962 MUST exist between the LAC and LNS. This is the same shared secret 1963 used for AVP hiding (see section 4.3). See section 4.4.3 for 1964 details on construction of the Challenge and Response AVPs. 1966 5.2 Session Establishment 1968 After successful control connection establishment, individual 1969 sessions may be created. Each session corresponds to single PPP 1970 stream between the LAC and LNS. Unlike control connection 1971 establishment, session establishment is directional with respect to 1972 the LAC and LNS. The LAC requests the LNS to accept a session for an 1973 incoming call, and the LNS requests the LAC to accept a session for 1974 placing an outgoing call. 1976 5.2.1 Incoming Call Establishment 1978 A three message exchange is employed to setup the session. 1979 Following is a typical sequence of events: 1981 LAC LNS 1982 --- --- 1983 (Call 1984 Detected) 1986 ICRQ -> 1987 <- ICRP 1988 ICCN -> 1989 <- ZLB ACK 1991 The ZLB ACK is sent if there are no further messages waiting in 1992 queue for that peer. 1994 5.2.2 Outgoing Call Establishment 1996 A three message exchange is employed to setup the session. 1997 Following is a typical sequence of events: 1999 LAC LNS 2000 --- --- 2001 <- OCRQ 2002 OCRP -> 2004 (Perform 2005 Call 2006 Operation) 2008 OCCN -> 2009 <- ZLB ACK 2011 The ZLB ACK is sent if there are no further messages waiting in 2012 queue for that peer. 2014 5.3 Forwarding PPP Frames 2016 Once tunnel establishment is complete, PPP frames from the remote 2017 system are received at the LAC, stripped of CRC, link framing, and 2018 transparency bytes, encapsulated in L2TP, and forwarded over the 2019 appropriate tunnel. The LNS receives the L2TP packet, and processes 2020 the encapsulated PPP frame as if it were received on a local PPP 2021 interface. 2023 The sender of a message associated with a particular session and 2024 tunnel places the Session ID and Tunnel ID (specified by its peer) in 2025 the Session ID and Tunnel ID header for all outgoing messages. In 2026 this manner, PPP frames are multiplexed and demultiplexed over a 2027 single tunnel between a given LNS-LAC pair. Multiple tunnels may 2028 exist between a given LNS-LAC pair, and multiple sessions may exist 2029 within a tunnel. 2031 The value of 0 for Session ID and Tunnel ID is special and MUST NOT 2032 be used as an Assigned Session ID or Assigned Tunnel ID. For the 2033 cases where a Session ID has not yet been assigned by the peer (i.e., 2034 during establishment of a new session or tunnel), the Session ID 2035 field MUST be sent as 0, and the Assigned Session ID AVP within the 2036 message MUST be used to identify the session. Similarly, for cases 2037 where the Tunnel ID has not yet been assigned from the peer, the 2038 Tunnel ID MUST be sent as 0 and Assigned Tunnel ID AVP used to 2039 identify the tunnel. 2041 5.4 Using Sequence Numbers on the Data Channel 2043 Sequence numbers are defined in the L2TP header for control messages 2044 and optionally for data messages (see section 3.1). These are used to 2045 provide a reliable control message transport (see section 5.8) and 2046 optional data message sequencing. Each peer maintains separate 2047 sequence numbers for the control connection and each individual data 2048 session within a tunnel. 2050 Unlike the L2TP control channel, the L2TP data channel does not use 2051 sequence numbers to retransmit lost data messages. Rather, data 2052 messages may use sequence numbers to detect lost packets and/or 2053 restore the original sequence of packets that may have been reordered 2054 during transport. The LAC may request that sequence numbers be 2055 present in data messages via the Sequencing Required AVP (see section 2056 4.4.6). If this AVP is present during session setup, sequence numbers 2057 MUST be present at all times at the LNS and LAC. 2059 If the Sequencing Required AVP is not present, sequence number 2060 presence is under control of the LNS. The LNS controls enabling and 2061 disabling of sequence numbers by sending a data message with or 2062 without sequence numbers present at any time during the life of a 2063 session. Thus, if the LAC receives a data message without sequence 2064 numbers present, it MUST stop sending sequence numbers in future data 2065 messages. If the LAC receives a data message with sequence numbers 2066 present, it MUST begin sending sequence numbers in future outgoing 2067 data messages. If the LNS enables sequencing after disabling it 2068 earlier in the session, the sequence number count picks up where it 2069 left off before. 2071 The LNS may initiate disabling of sequencing at any time during the 2072 session (including the first data message sent). It is recommended 2073 that for connections where reordering or packet loss may occur, 2074 sequence numbers always be enabled during the initial negotiation 2075 stages of PPP and disabled only when and if the risk is considered 2076 acceptable. For example, if the PPP session being tunneled is not 2077 utilizing any stateful compression or encryption protocols and is 2078 only carrying IP (as determined by the PPP NCPs that are 2079 established), then the LNS might decide to disable sequencing as IP 2080 is tolerant to datagram loss and reordering. 2082 5.5 Keepalive (Hello) 2084 A keepalive mechanism is employed by L2TP in order to differentiate 2085 tunnel outages from extended periods of no control or data activity 2086 on a tunnel. This is accomplished by injecting Hello control messages 2087 (see section 6.5) after a specified period of time has elapsed since 2088 the last data or control message was received on a tunnel. As for any 2089 other control message, if the Hello message is not reliably delivered 2090 then the tunnel is declared down and is reset. The transport reset 2091 mechanism along with the injection of Hello messages ensures that a 2092 connectivity failure between the LNS and the LAC will be detected at 2093 both ends of a tunnel. 2095 5.6 Session Teardown 2097 Session teardown may be initiated by either the LAC or LNS and is 2098 accomplished by sending a CDN control message. After the last session 2099 is cleared, the control connection MAY be torn down as well (and 2100 typically is). Following is an example of a typical control message 2101 exchange: 2103 LAC or LNS LAC or LNS 2105 CDN -> 2106 (Clean up) 2108 <- ZLB ACK 2109 (Clean up) 2111 5.7 Control Connection Teardown 2113 Control connection teardown may be initiated by either the LAC or LNS 2114 and is accomplished by sending a single StopCCN control message. The 2115 receiver of a StopCCN MUST send a ZLB ACK to acknowledge receipt of 2116 the message and maintain enough control connection state to properly 2117 accept StopCCN retransmissions over at least a full retransmission 2118 cycle (in case the ZLB ACK is lost). The recommended time for a full 2119 retransmission cycle is 31 seconds (see section 5.8). Following is an 2120 example of a typical control message exchange: 2122 LAC or LNS LAC or LNS 2124 StopCCN -> 2125 (Clean up) 2127 <- ZLB ACK 2128 (Wait) 2129 (Clean up) 2131 An implementation may shut down an entire tunnel and all sessions on 2132 the tunnel by sending the StopCCN. Thus, it is not necessary to clear 2133 each session individually when tearing down the whole tunnel. 2135 5.8 Reliable Delivery of Control Messages 2137 L2TP provides a lower level reliable transport service for all 2138 control messages. The Nr and Ns fields of the control message header 2139 (see section 3.1) belong to this transport. The upper level 2140 functions of L2TP are not concerned with retransmission or ordering 2141 of control messages. The reliable control message is a sliding window 2142 transport that provides control message retransmission and congestion 2143 control. Each peer maintains separate sequence number state for the 2144 control connection within a tunnel. 2146 The message sequence number, Ns, begins at 0. Each subsequent message 2147 is sent with the next increment of the sequence number. The sequence 2148 number is thus a free running counter represented modulo 65536. The 2149 sequence number in the header of a received message is considered 2150 less than or equal to the last received number if its value lies in 2151 the range of the last received number and the preceding 32767 values, 2152 inclusive. For example, if the last received sequence number was 15, 2153 then messages with sequence numbers 0 through 15, as well as 32784 2154 through 65535, would be considered less than or equal. Such a message 2155 would be considered a duplicate of a message already received and 2156 ignored from processing. However, in order to ensure that all 2157 messages are acknowledged properly (particularly in the case of a 2158 lost ZLB ACK message), receipt of duplicate messages MUST be 2159 acknowledged by the reliable transport. This acknowledgement may 2160 either piggybacked on a message in queue, or explicitly via a ZLB 2161 ACK. 2163 All control messages take up one slot in the control message sequence 2164 number space, except the ZLB acknowledgement. Thus, Ns is not 2165 incremented after a ZLB message is sent. 2167 The last received message number, Nr, is used to acknowledge messages 2168 received by an L2TP peer. It contains the sequence number of the 2169 message the peer expects to receive next (e.g. the last Ns of a non- 2170 ZLB message received plus 1, modulo 65536). While the Nr in a 2171 received ZLB is used to flush messages from the local retransmit 2172 queue (see below), Nr of the next message sent is not be updated by 2173 the Ns of the ZLB. As a precaution, Nr should be sanity checked 2174 before flushing the retransmit queue. e.g. if the Nr received in a 2175 control message is greater than the last Ns sent plus 1 modulo 65536, 2176 it is clearly invalid. 2178 The reliable transport at a receiving peer is responsible for making 2179 sure that control messages are delivered in order and without 2180 duplication to the upper level. Messages arriving out of order may be 2181 queued for in-order delivery when the missing messages are received, 2182 or they may be discarded requiring a retransmission by the peer. When 2183 dropping out of order control packets, Nr MAY be updated before the 2184 packet is discarded. 2186 Each tunnel maintains a queue of control messages to be transmitted 2187 to its peer. The message at the front of the queue is sent with a 2188 given Ns value, and is held until a control message arrives from the 2189 peer in which the Nr field indicates receipt of this message. After a 2190 period of time (a recommended default is 1 second) passes without 2191 acknowledgement, the message is retransmitted. The retransmitted 2192 message contains the same Ns value, but the Nr value MUST be updated 2193 with the sequence number of the next expected message. 2195 Each subsequent retransmission of a message MUST employ an 2196 exponential backoff interval. Thus, if the first retransmission 2197 occurred after 1 second, the next retransmission should occur after 2 2198 seconds has elapsed, then 4 seconds, etc. An implementation MAY place 2199 a cap upon the maximum interval between retransmissions. This cap 2200 MUST be no less than 8 seconds per retransmission. If no peer 2201 response is detected after several retransmissions, (a recommended 2202 default is 5, but SHOULD be configurable), the tunnel and all 2203 sessions within MUST be cleared. 2205 When a tunnel is being shut down for reasons other than loss of 2206 connectivity, the state and reliable delivery mechanisms MUST be 2207 maintained and operated for the full retransmission interval after 2208 the final message exchange has occurred. 2210 A sliding window mechanism is used for control message transmission. 2211 Consider two peers A & B. Suppose A specifies a Receive Window Size 2212 AVP with a value of N in the SCCRQ or SCCRP messages. B is now 2213 allowed to have up to N outstanding control messages. Once N have 2214 been sent, it must wait for an acknowledgment that advances the 2215 window before sending new control messages. An implementation may 2216 support a receive window of only 1 (e.g. by sending out a Receive 2217 Window Size AVP with a value of 1), but MUST accept a window of up to 2218 4 from its peer (e.g. have the ability to send 4 messages before 2219 backing off). A value of 0 for the Receive Window Size AVP is 2220 invalid. 2222 When retransmitting control messages, a slow start and congestion 2223 avoidance window adjustment procedure SHOULD be utilized. The 2224 recommended procedure for this is described in Appendix A. 2226 A peer MUST NOT withhold acknowledgment of messages as a technique 2227 for flow controlling control messages. An L2TP implementation is 2228 expected to be able to keep up with incoming control messages, 2229 possibly responding to some with errors reflecting an inability to 2230 honor the requested action. 2232 Appendix B contains examples of control message transmission, 2233 acknowledgement, and retransmission. 2235 6.0 Control Connection Protocol Specification 2237 The following control connection messages are used to establish, 2238 clear and maintain L2TP tunnels. All data is sent in network order 2239 (high order octets first). Any "reserved" or "empty" fields MUST be 2240 sent as 0 values to allow for protocol extensibility. 2242 6.1 Start-Control-Connection-Request (SCCRQ) 2244 Start-Control-Connection-Request (SCCRQ) is a control message used to 2245 initialize a tunnel between an LNS and an LAC. It is sent by either 2246 the LAC or the LNS to being the tunnel establishment process. 2248 The following AVPs MUST be present in the SCCRQ: 2250 Message Type AVP 2251 Protocol Version 2252 Host Name 2253 Framing Capabilities 2254 Assigned Tunnel ID 2256 The Following AVPs MAY be present in the SCCRQ: 2258 Bearer Capabilities 2259 Receive Window Size 2260 Challenge 2261 Tie Breaker 2262 Firmware Revision 2263 Vendor Name 2265 6.2 Start-Control-Connection-Reply (SCCRP) 2267 Start-Control-Connection-Reply (SCCRP) is a control message sent in 2268 reply to a received SCCRQ message. SCCRP is used to indicate that the 2269 SCCRQ was accepted and establishment of the tunnel should continue. 2271 The following AVPs MUST be present in the SCCRP: 2273 Message Type 2274 Protocol Version 2275 Framing Capabilities 2276 Host Name 2277 Assigned Tunnel ID 2279 The following AVPs MAY be present in the SCCRP: 2281 Bearer Capabilities 2282 Firmware Revision 2283 Vendor Name 2284 Receive Window Size 2285 Challenge 2286 Challenge Response 2288 6.3 Start-Control-Connection-Connected (SCCCN) 2290 Start-Control-Connection-Connected (SCCCN) is a control message sent 2291 in reply to an SCCRP. SCCCN completes the tunnel establishment 2292 process. 2294 The following AVP MUST be present in the SCCCN: 2296 Message Type 2298 The following AVP MAY be present in the SCCCN: 2300 Challenge Response 2302 6.4 Stop-Control-Connection-Notification (StopCCN) 2304 Stop-Control-Connection-Notification (StopCCN) is a control message 2305 sent by either the LAC or LNS to inform its peer that the tunnel is 2306 being shutdown and the control connection should be closed. In 2307 addition, all active sessions are implicitly cleared (without sending 2308 any explicit call control messages). The reason for issuing this 2309 request is indicated in the Result Code AVP. There is no explicit 2310 reply to the message, only the implicit ACK that is received by the 2311 reliable control message transport layer. 2313 The following AVPs MUST be present in the StopCCN: 2315 Message Type 2316 Result Code 2318 The Assigned Tunnel ID MUST be present in the StopCCN if it has been 2319 sent in a previous message (see section 4.4.3). 2321 6.5 Hello (HELLO) 2323 The Hello (HELLO) message is an L2TP control message sent by either 2324 peer of a LAC-LNS control connection. This control message is used as 2325 a "keepalive" for the tunnel. 2327 The sending of HELLO messages and the policy for sending them are 2328 left up to the implementation. A peer MUST NOT expect HELLO messages 2329 at any time or interval. As with all messages sent on the control 2330 connection, the receiver will return either a ZLB ACK or an 2331 (unrelated) message piggybacking the necessary acknowledgement 2332 information. 2334 Since a HELLO is a control message, and control messages are reliably 2335 sent by the lower level transport, this keepalive function operates 2336 by causing the transport level to reliably deliver a message. If a 2337 media interruption has occurred, the reliable transport will be 2338 unable to deliver the HELLO across, and will clean up the tunnel. 2340 Keepalives for the tunnel MAY be implemented by sending a HELLO if a 2341 period of time (a recommended default is 60 seconds, but SHOULD be 2342 configurable) has passed without receiving any message (data or 2343 control) from the peer. 2345 HELLO messages are global to the tunnel. The Session ID in a HELLO 2346 message MUST be 0. 2348 The Following AVP MUST be present in the HELLO message: 2350 Message Type 2352 6.6 Incoming-Call-Request (ICRQ) 2354 Incoming-Call-Request (ICRQ) is a control message sent by the LAC to 2355 the LNS when an incoming call is detected. It is the first in a three 2356 message exchange used for establishing a session within an L2TP 2357 tunnel. 2359 ICRQ is used to indicate that a session is to be established between 2360 the LAC and LNS for this call and provides the LNS with parameter 2361 information for the session. The LAC may defer answering the call 2362 until it has received an ICRP from the LNS indicating that the 2363 session should be established. This mechanism allows the LNS to 2364 obtain sufficient information about the call before determining 2365 whether it should be answered or not. Alternatively, the LAC may 2366 answer the call, negotiate LCP and PPP authentication, and use the 2367 information gained to choose the LNS. In this case, the call has 2368 already been answered by the time the ICRP message is received; the 2369 LAC simply spoofs the "call indication" and "call answer" steps in 2370 this case. 2372 The following AVPs MUST be present in the ICRQ: 2374 Message Type 2375 Assigned Session ID 2376 Call Serial Number 2378 The following AVPs MAY be present in the ICRQ: 2380 Bearer Type 2381 Physical Channel ID 2382 Calling Number 2383 Called Number 2384 Sub-Address 2386 6.7 Incoming-Call-Reply (ICRP) 2388 Incoming-Call-Reply (ICRP) is a control message sent by the LNS to 2389 the LAC in response to a received ICRQ message. It is the second in 2390 the three message exchange used for establishing sessions within an 2391 L2TP tunnel. 2393 ICRP is used to indicate that the ICRQ was successful and for the LAC 2394 to answer the call if it has not already done so. It also allows the 2395 LNS to indicate necessary parameters for the L2TP session. 2397 The following AVPs MUST be present in the ICRP: 2399 Message Type 2400 Assigned Session ID 2402 6.8 Incoming-Call-Connected (ICCN) 2404 Incoming-Call-Connected (ICCN) is a control message sent by the LAC 2405 to the LNS in response to a received ICRP message. It is the third 2406 message in the three message exchange used for establishing sessions 2407 within an L2TP tunnel. 2409 ICCN is used to indicate that the ICRP was accepted, the call has 2410 been answered, and that the L2TP session should move to the 2411 established state. It also provides additional information to the 2412 LNS about parameters used for the answered call (parameters that may 2413 not always available at the time the ICRQ is issued). 2415 If the ICCN is carrying crucial PPP initialization information (such 2416 as Proxy LCP or Auth), the LAC SHOULD wait until the ICCN has been 2417 acknowledged before sending data messages. This is recommended 2418 because (1) there is no guarantee that the ICCN and first data 2419 messages will not be reordered during transit, and (2) the LNS may 2420 take some time to initialize its PPP session with the proxied 2421 information. 2423 The following AVPs MUST be present in the ICCN: 2425 Message Type 2426 (Tx) Connect Speed 2427 Framing Type 2429 The following AVPs MAY be present in the ICCN: 2431 Initial Received LCP CONFREQ 2432 Last Sent LCP CONFREQ 2433 Last Received LCP CONFREQ 2434 Proxy Authen Type 2435 Proxy Authen Name 2436 Proxy Authen Challenge 2437 Proxy Authen ID 2438 Proxy Authen Response 2439 Private Group ID 2440 Rx Connect Speed 2441 Sequencing Required 2443 6.9 Outgoing-Call-Request (OCRQ) 2445 Outgoing-Call-Request (OCRQ) is a control message sent by the LNS to 2446 the LAC to indicate that an outbound call from the LAC is to be 2447 established. It is the first in a three message exchange used for 2448 establishing a session within an L2TP tunnel. 2450 OCRQ is used to indicate that a session is to be established between 2451 the LNS and LAC for this call and provides the LAC with parameter 2452 information for both the L2TP session, and the call that is to be 2453 placed 2455 An LNS MUST have received a Bearer Capabilities AVP during tunnel 2456 establishment from an LAC in order to request an outgoing call to 2457 that LAC. 2459 The following AVPs MUST be present in the OCRQ: 2461 Message Type 2462 Assigned Session ID 2463 Call Serial Number 2464 Minimum BPS 2465 Maximum BPS 2466 Bearer Type 2467 Framing Type 2468 Called Number 2470 The following AVPs MAY be present in the OCRQ: 2472 Sub-Address 2474 6.10 Outgoing-Call-Reply (OCRP) 2476 Outgoing-Call-Reply (OCRP) is a control message sent by the LAC to 2477 the LNS in response to a received OCRQ message. It is the second in a 2478 three message exchange used for establishing a session within an L2TP 2479 tunnel. 2481 OCRP is used to indicate that the LAC is able to attempt the outbound 2482 call and returns certain parameters regarding the call attempt. 2484 The following AVPs MUST be present in the OCRP: 2486 Message Type 2487 Assigned Session ID 2489 The following AVPs MAY be present in the OCRP: 2491 Physical Channel ID 2493 6.11 Outgoing-Call-Connected (OCCN) 2495 Outgoing-Call-Connected (OCCN) is a control message sent by the LAC 2496 to the LNS following the OCRP and after the outgoing call has been 2497 completed. It is the final message in a three message exchange used 2498 for establishing a session within an L2TP tunnel. 2500 OCCN is used to indicate that the result of a requested outgoing call 2501 was successful. It also provides information to the LNS about the 2502 particular parameters obtained after the call was established. 2504 The following AVPs MUST be present in the OCCN: 2506 Message Type 2507 (Tx) Connect Speed 2508 Framing Type 2510 The following AVPs MAY be present in the OCCN: 2512 Rx Connect Speed 2513 Sequencing Required 2515 6.12 Call-Disconnect-Notify (CDN) 2517 The Call-Disconnect-Notify (CDN) message is an L2TP control message 2518 sent by either the LAC or LNS to request disconnection of a specific 2519 call within the tunnel. Its purpose is to inform the peer of the 2520 disconnection and the reason why the disconnection occurred. The peer 2521 MUST clean up any resources, and does not send back any indication of 2522 success or failure for such cleanup. 2524 The following AVPs MUST be present in the CDN: 2526 Message Type 2527 Result Code 2529 The Assigned Session ID MUST be present in the CDN if it has been 2530 sent in a previous message (see section 4.4.3). 2532 The following AVPs MAY be present in the CDN: 2534 Q.931 Cause Code 2536 6.13 WAN-Error-Notify (WEN) 2538 The WAN-Error-Notify message is an L2TP control message sent by the 2539 LAC to the LNS to indicate WAN error conditions (conditions that 2540 occur on the interface supporting PPP). The counters in this message 2541 are cumulative. This message should only be sent when an error 2542 occurs, and not more than once every 60 seconds. The counters are 2543 reset when a new call is established. 2545 The following AVPs MUST be present in the WEN: 2547 Message Type 2548 Call Errors 2550 6.14 Set-Link-Info (SLI) 2552 The Set-Link-Info message is an L2TP control message sent by the LNS 2553 to the LAC after the last LCP Conf ACK is received during PPP LCP 2554 negotiation. This AVP contains any relevant link level parameters 2555 that the LAC may need to be aware of (for instance, ACCM map info). 2556 If there is no relevant information to be sent in the SLI, then it 2557 MAY be omitted. Since LCP may be renegotiated at any time, an SLI 2558 may be sent at any time during the life of the call, thus the LAC 2559 MUST be able to update its internal call information and behavior on 2560 an active session. Further, if there are packets in queue at the LAC 2561 when an SLI is received, these must be flushed before applying the 2562 SLI information to the link. 2564 If the PPP session at the LNS renegotiates LCP during the call, an 2565 SLI MUST be sent to the LAC to return link level information to the 2566 initial default values while the negotiation occurs. However, if the 2567 last SLI sent was already set to default values or no SLI was sent at 2568 all, this step MAY be omitted. 2570 The following AVPs MUST be present in the SLI: 2572 Message Type 2573 ACCM 2575 7.0 Control Connection State Machines 2577 State tables defined in this section govern the exchange of control 2578 messages defined in section 6. Tables are defined for incoming call 2579 placement, outgoing call placement, as well as for initiation of the 2580 tunnel itself. The state tables do not encode timeout and 2581 retransmission behavior, as this is handled in the underlying 2582 transport defined in section 5.8. 2584 7.1 Control Connection Protocol Operation 2586 This section describes the operation of various L2TP control 2587 connection functions and the Control Connection messages which are 2588 used to support them. 2590 Receipt of an invalid or unrecoverable malformed control message 2591 should be logged appropriately and the control connection cleared to 2592 ensure recovery to a known state. The control connection may then be 2593 restarted by the initiator. 2595 An invalid control message is defined as a message which contains a 2596 Message Type that is marked mandatory (see section 4.4.1) and is 2597 unknown to the implementation, or a control message that is received 2598 in an improper sequence (e.g. an SCCCN sent in reply to an SCCRQ). 2600 Examples of a malformed control message include one that has an 2601 invalid value in its header, contains an AVP that is formatted 2602 incorrectly or whose value is out of range, or a message that is 2603 missing a required AVP. A control message with a malformed header 2604 should be discarded. A control message with an invalid AVP should 2605 look to the M-bit for that AVP to determine whether the error is 2606 recoverable or not. 2608 A malformed yet recoverable non-mandatory (M-bit is not set) AVP 2609 within a control message should be treated in a similar manner as an 2610 unrecognized non-mandatory AVP. Thus, if a malformed AVP is received 2611 with the M-bit set, the session or tunnel should be terminated with a 2612 proper Result or Error Code sent. If the M-bit is not set, the AVP 2613 should be ignored (with the exception of logging a local error 2614 message) and the message accepted. 2616 This MUST NOT be considered a license to send malformed AVPs, but 2617 simply a guide towards how to handle an improperly formatted message 2618 if one is received. It is impossible to list all potential 2619 malformations of a given message and give advice for each. That said, 2620 one example of a recoverable, malformed AVP might be if the Rx 2621 Connect Speed AVP, attribute 38, is received with a length of 8 2622 rather than 10 and the BPS given in 2 octets rather than 4. Since the 2623 Rx Connect Speed is non-mandatory, this condition should not be 2624 considered catastrophic. As such, the control message should be 2625 accepted as if the AVP had not been received (with the exception of a 2626 local error message being logged). 2628 In several cases in the following tables, a protocol message is sent, 2629 and then a "clean up" occurs. Note that regardless of the initiator 2630 of the tunnel destruction, the reliable delivery mechanism must be 2631 allowed to run (see section 5.8) before destroying the tunnel. This 2632 permits the tunnel management messages to be reliably delivered to 2633 the peer. 2635 Appendix B.1 contains an example of lock-step tunnel establishment. 2637 7.2 Control Connection States 2639 The L2TP control connection protocol is not distinguishable between 2640 the LNS and LAC, but is distinguishable between the originator and 2641 receiver. The originating peer is the one which first initiates 2642 establishment of the tunnel (in a tie breaker situation, this is the 2643 winner of the tie). Since either LAC or LNS can be the originator, a 2644 collision can occur. See the Tie Breaker AVP in section 4.4.3 for a 2645 description of this and its resolution. 2647 7.2.1 Control Connection Establishment 2649 State Event Action New State 2650 ----- ----- ------ --------- 2651 idle Local Send SCCRQ wait-ctl-reply 2652 Open request 2654 idle Receive SCCRQ, Send SCCRP wait-ctl-conn 2655 acceptable 2657 idle Receive SCCRQ, Send StopCCN, idle 2658 not acceptable Clean up 2660 idle Receive SCCRP Send StopCCN idle 2661 Clean up 2663 idle Receive SCCCN Clean up idle 2664 wait-ctl-reply Receive SCCRP, Send SCCCN, established 2665 acceptable Send tunnel-open 2666 event to waiting 2667 sessions 2669 wait-ctl-reply Receive SCCRP, Send StopCCN, idle 2670 not acceptable Clean up 2672 wait-ctl-reply Receive SCCRQ, Clean up, idle 2673 lose tie-breaker Re-queue SCCRQ 2674 for idle state 2676 wait-ctl-reply Receive SCCCN Send StopCCN idle 2677 Clean up 2679 wait-ctl-conn Receive SCCCN, Send tunnel-open established 2680 acceptable event to waiting 2681 sessions 2683 wait-ctl-conn Receive SCCCN, Send StopCCN, idle 2684 not acceptable Clean up 2686 wait-ctl-conn Receive SCCRP, Send StopCCN, idle 2687 SCCRQ Clean up 2689 established Local Send tunnel-open established 2690 Open request event to waiting 2691 (new call) sessions 2693 established Admin Send StopCCN idle 2694 Tunnel Close Clean up 2696 established Receive SCCRQ, Send StopCCN idle 2697 SCCRP, SCCCN Clean up 2699 idle Receive StopCCN Clean up idle 2700 wait-ctl-reply, 2701 wait-ctl-conn, 2702 established 2704 The states associated with the LNS or LAC for control connection 2705 establishment are: 2707 idle 2708 Both initiator and recipient start from this state. An initiator 2709 transmits an SCCRQ, while a recipient remains in the idle state 2710 until receiving an SCCRQ. 2712 wait-ctl-reply 2713 The originator checks to see if another connection has been 2714 requested from the same peer, and if so, handles the collision 2715 situation described in section 5.8. 2717 When an SCCRP is received, it is examined for a compatible 2718 version. If the version of the reply is lower than the version 2719 sent in the request, the older (lower) version should be used 2720 provided it is supported. If the version in the reply is earlier 2721 and supported, the originator moves to the established state. If 2722 the version is earlier and not supported, a StopCCN MUST be sent 2723 to the peer and the originator cleans up and terminates the 2724 tunnel. 2726 wait-ctl-conn 2727 This is where an SCCCN is awaited; upon receipt, the challenge 2728 response is checked. The tunnel either is established, or is torn 2729 down if an authorization failure is detected. 2731 established 2732 An established connection may be terminated by either a local 2733 condition or the receipt of a Stop-Control-Connection- 2734 Notification. In the event of a local termination, the originator 2735 MUST send a Stop-Control-Connection-Notification and clean up the 2736 tunnel. 2738 If the originator receives a Stop-Control-Connection-Notification 2739 it MUST also clean up the tunnel. 2741 7.3 Timing considerations 2743 Due to the real-time nature of telephone signaling, both the LNS and 2744 LAC should be implemented with multi-threaded architectures such that 2745 messages related to multiple calls are not serialized and blocked. 2746 The call and connection state figures do not specify exceptions 2747 caused by timers. These are addressed in section 5.8. 2749 7.4 Incoming calls 2751 An Incoming-Call-Request message is generated by the LAC when an 2752 incoming call is detected (for example, an associated telephone line 2753 rings). The LAC selects a Session ID and serial number and indicates 2754 the call bearer type. Modems should always indicate analog call type. 2755 ISDN calls should indicate digital when unrestricted digital service 2756 or rate adaptation is used and analog if digital modems are involved. 2757 Calling Number, Called Number, and Subaddress may be included in the 2758 message if they are available from the telephone network. 2760 Once the LAC sends the Incoming-Call-Request, it waits for a response 2761 from the LNS but it does not necessarily answer the call from the 2762 telephone network yet. The LNS may choose not to accept the call if: 2764 - No resources are available to handle more sessions 2765 - The dialed, dialing, or subaddress fields do not correspond to 2766 an authorized user 2767 - The bearer service is not authorized or supported 2769 If the LNS chooses to accept the call, it responds with an Incoming- 2770 Call-Reply. When the LAC receives the Incoming-Call-Reply, it 2771 attempts to connect the call. A final call connected message from 2772 the LAC to the LNS indicates that the call states for both the LAC 2773 and the LNS should enter the established state. If the call 2774 terminated before the LNS could accept it, a Call-Disconnect-Notify 2775 is sent by the LAC to indicate this condition. 2777 When the dialed-in client hangs up, the call is cleared normally and 2778 the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to 2779 clear a call, it sends a Call-Disconnect-Notify message and cleans up 2780 its session. 2782 7.4.1 LAC Incoming Call States 2784 State Event Action New State 2785 ----- ----- ------ --------- 2786 idle Bearer Ring or Initiate local wait-tunnel 2787 Ready to indicate tunnel open 2788 incoming conn. 2790 idle Receive ICCN, Clean up idle 2791 ICRP, CDN 2793 wait-tunnel Bearer line drop Clean up idle 2794 or local close 2795 request 2797 wait-tunnel tunnel-open Send ICRQ wait-reply 2799 wait-reply Receive ICRP, Send ICCN established 2800 acceptable 2802 wait-reply Receive ICRP, Send CDN, idle 2803 Not acceptable Clean up 2805 wait-reply Receive ICRQ Send CDN idle 2806 Clean up 2808 wait-reply Receive CDN Clean up idle 2809 ICCN 2811 wait-reply Local Send CDN, idle 2812 close request or Clean up 2813 Bearer line drop 2815 established Receive CDN Clean up idle 2817 established Receive ICRQ, Send CDN, idle 2818 ICRP, ICCN Clean up 2820 established Bearer line Send CDN, idle 2821 drop or local Clean up 2822 close request 2824 The states associated with the LAC for incoming calls are: 2826 idle 2827 The LAC detects an incoming call on one of its interfaces. 2828 Typically this means an analog line is ringing or an ISDN TE has 2829 detected an incoming Q.931 SETUP message. The LAC initiates its 2830 tunnel establishment state machine, and moves to a state waiting 2831 for confirmation of the existence of a tunnel. 2833 wait-tunnel 2834 In this state the session is waiting for either the control 2835 connection to be opened or for verification that the tunnel is 2836 already open. Once an indication that the tunnel has/was opened, 2837 session control messages may be exchanged. The first of these is 2838 the Incoming-Call-Request. 2840 wait-reply 2841 The LAC receives either a CDN message indicating the LNS is not 2842 willing to accept the call (general error or don't accept) and 2843 moves back into the idle state, or an Incoming-Call-Reply message 2844 indicating the call is accepted, the LAC sends an Incoming-Call- 2845 Connected message and enters the established state. 2847 established 2848 Data is exchanged over the tunnel. The call may be cleared 2849 following: 2850 + An event on the connected interface: The LAC sends a Call- 2851 Disconnect-Notify message 2852 + Receipt of a Call-Disconnect-Notify message: The LAC cleans 2853 up, disconnecting the call. 2854 + A local reason: The LAC sends a Call-Disconnect-Notify 2855 message. 2857 7.4.2 LNS Incoming Call States 2859 State Event Action New State 2860 ----- ----- ------ --------- 2861 idle Receive ICRQ, Send ICRP wait-connect 2862 acceptable 2864 idle Receive ICRQ, Send CDN, idle 2865 not acceptable Clean up 2867 idle Receive ICRP Send CDN idle 2868 Clean up 2870 idle Receive ICCN Clean up idle 2872 wait-connect Receive ICCN Prepare for established 2873 acceptable data 2875 wait-connect Receive ICCN Send CDN, idle 2876 not acceptable Clean up 2878 wait-connect Receive ICRQ, Send CDN idle 2879 ICRP Clean up 2881 idle, Receive CDN Clean up idle 2882 wait-connect, 2883 established 2885 wait-connect Local Send CDN, idle 2886 established Close request Clean up 2888 established Receive ICRQ, Send CDN idle 2889 ICRP, ICCN Clean up 2891 The states associated with the LNS for incoming calls are: 2893 idle 2894 An Incoming-Call-Request message is received. If the request is 2895 not acceptable, a Call-Disconnect-Notify is sent back to the LAC 2896 and the LNS remains in the idle state. If the Incoming-Call- 2897 Request message is acceptable, an Incoming-Call-Reply is sent. The 2898 session moves to the wait-connect state. 2900 wait-connect 2901 If the session is still connected on the LAC, the LAC sends an 2902 Incoming-Call-Connected message to the LNS which then moves into 2903 established state. The LAC may send a Call-Disconnect-Notify to 2904 indicate that the incoming caller could not be connected. This 2905 could happen, for example, if a telephone user accidentally places 2906 a standard voice call to an LAC resulting in a handshake failure 2907 on the called modem. 2909 established 2910 The session is terminated either by receipt of a Call-Disconnect- 2911 Notify message from the LAC or by sending a Call-Disconnect- 2912 Notify. Clean up follows on both sides regardless of the 2913 initiator. 2915 7.5 Outgoing calls 2917 Outgoing calls are initiated by an LNS and instruct an LAC to place a 2918 call. There are three messages for outgoing calls: Outgoing-Call- 2919 Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS 2920 sends an Outgoing-Call-Request specifying the dialed party phone 2921 number, subaddress and other parameters. The LAC MUST respond to the 2922 Outgoing-Call-Request message with an Outgoing-Call-Reply message 2923 once the LAC determines that the proper facilities exist to place the 2924 call and the call is administratively authorized. For example, is 2925 this LNS allowed to dial an international call? Once the outbound 2926 call is connected, the LAC sends an Outgoing-Call-Connected message 2927 to the LNS indicating the final result of the call attempt: 2929 7.5.1 LAC Outgoing Call States 2931 State Event Action New State 2932 ----- ----- ------ --------- 2933 idle Receive OCRQ, Send OCRP, wait-cs-answer 2934 acceptable Open bearer 2936 idle Receive OCRQ, Send CDN, idle 2937 not acceptable Clean up 2939 idle Receive OCRP Send CDN idle 2940 Clean up 2942 idle Receive OCCN, Clean up idle 2943 CDN 2945 wait-cs-answer Bearer answer, Send OCCN established 2946 framing detected 2948 wait-cs-answer Bearer failure Send CDN, idle 2949 Clean up 2951 wait-cs-answer Receive OCRQ, Send CDN idle 2952 OCRP, OCCN Clean up 2954 established Receive OCRQ, Send CDN idle 2955 OCRP, OCCN Clean up 2957 wait-cs-answer, Receive CDN Clean up idle 2958 established 2960 established Bearer line drop, Send CDN, idle 2961 Local close Clean up 2962 request 2964 The states associated with the LAC for outgoing calls are: 2966 idle 2967 If Outgoing-Call-Request is received in error, respond with a 2968 Call-Disconnect-Notify. Otherwise, allocate a physical channel and 2969 send an Outgoing-Call-Reply. Place the outbound call and move to 2970 the wait-cs-answer state. 2972 wait-cs-answer 2973 If the call is not completed or a timer expires waiting for the 2974 call to complete, send a Call-Disconnect-Notify with the 2975 appropriate error condition set and go to idle state. If a circuit 2976 switched connection is established and framing is detected, send 2977 an Outgoing-Call-Connected indicating success and go to 2978 established state. 2980 established 2981 If a Call-Disconnect-Notify is received by the LAC, the telco call 2982 MUST be released via appropriate mechanisms and the session 2983 cleaned up. If the call is disconnected by the client or the 2984 called interface, a Call-Disconnect-Notify message MUST be sent to 2985 the LNS. The sender of the Call-Disconnect-Notify message returns 2986 to the idle state after sending of the message is complete. 2988 7.5.2 LNS Outgoing Call States 2990 State Event Action New State 2991 ----- ----- ------ --------- 2992 idle Local Initiate local wait-tunnel 2993 open request tunnel-open 2995 idle Receive OCCN, Clean up idle 2996 OCRP, CDN 2998 wait-tunnel tunnel-open Send OCRQ wait-reply 3000 wait-reply Receive OCRP, none wait-connect 3001 acceptable 3003 wait-reply Receive OCRP, Send CDN idle 3004 not acceptable Clean up 3006 wait-reply Receive OCCN, Send CDN idle 3007 OCRQ Clean up 3009 wait-connect Receive OCCN none established 3011 wait-connect Receive OCRQ, Send CDN idle 3012 OCRP Clean up 3014 idle, Receive CDN, Clean up idle 3015 wait-reply, 3016 wait-connect, 3017 established 3019 established Receive OCRQ, Send CDN idle 3020 OCRP, OCCN Clean up 3022 wait-reply, Local Send CDN idle 3023 wait-connect, Close request Clean up 3024 established 3026 wait-tunnel Local Clean up idle 3027 Close request 3029 The states associated with the LNS for outgoing calls are: 3031 idle, wait-tunnel 3032 When an outgoing call is initiated, a tunnel is first created, 3033 much as the idle and wait-tunnel states for an LAC incoming call. 3034 Once a tunnel is established, an Outgoing-Call-Request message is 3035 sent to the LAC and the session moves into the wait-reply state. 3037 wait-reply 3038 If a Call-Disconnect-Notify is received, an error occurred, and 3039 the session is cleaned up and returns to idle. If an Outgoing- 3040 Call-Reply is received, the call is in progress and the session 3041 moves to the wait-connect state. 3043 wait-connect 3044 If a Call-Disconnect-Notify is received, the call failed; the 3045 session is cleaned up and returns to idle. If an Outgoing-Call- 3046 Connected is received, the call has succeeded and the session may 3047 now exchange data. 3049 established 3050 If a Call-Disconnect-Notify is received, the call has been 3051 terminated for the reason indicated in the Result and Cause Codes; 3052 the session moves back to the idle state. If the LNS chooses to 3053 terminate the session, it sends a Call-Disconnect-Notify to the 3054 LAC and then cleans up and idles its session. 3056 7.6 Tunnel Disconnection 3058 The disconnection of a tunnel consists of either peer issuing a 3059 Stop-Control-Connection-Notification. The sender of this Notification 3060 should wait a finite period of time for the acknowledgment of this 3061 message before releasing the control information associated with the 3062 tunnel. The recipient of this Notification should send an 3063 acknowledgment of the Notification and then release the associated 3064 control information. 3066 When to release a tunnel is an implementation issue and is not 3067 specified in this document. A particular implementation may use 3068 whatever policy is appropriate for determining when to release a 3069 control connection. Some implementations may leave a tunnel open for 3070 a period of time or perhaps indefinitely after the last session for 3071 that tunnel is cleared. Others may choose to disconnect the tunnel 3072 immediately after the last user connection on the tunnel disconnects. 3074 8.0 L2TP Over Specific Media 3076 L2TP is self-describing, operating at a level above the media over 3077 which it is carried. However, some details of its connection to media 3078 are required to permit interoperable implementations. The following 3079 sections describe details needed to permit interoperability over 3080 specific media. 3082 8.1 L2TP over UDP/IP 3084 L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP 3085 packet, including payload and L2TP header, is sent within a UDP 3086 datagram. The initiator of an L2TP tunnel picks an available source 3087 UDP port (which may or may not be 1701), and sends to the desired 3088 destination address at port 1701. The recipient picks a free port on 3089 its own system (which may or may not be 1701), and sends its reply to 3090 the initiator's UDP port and address, setting its own source port to 3091 the free port it found. Once the source and destination ports and 3092 addresses are established, they MUST remain static for the life of 3093 the tunnel. 3095 It has been suggested that having the recipient choose an arbitrary 3096 source port (as opposed to using the destination port in the packet 3097 initiating the tunnel, i.e., 1701) may make it more difficult for 3098 L2TP to traverse some NAT devices. Implementers should consider the 3099 potential implication of this before choosing an arbitrary source 3100 port. 3102 IP fragmentation may occur as the L2TP packet travels over the IP 3103 substrate. L2TP makes no special efforts to optimize this. A LAC 3104 implementation MAY cause its LCP to negotiate for a specific MRU, 3105 which could optimize for LAC environments in which the MTU's of the 3106 path over which the L2TP packets are likely to travel have a 3107 consistent value. 3109 The default for any L2TP implementation is that UDP checksums MUST be 3110 enabled for both control and data messages. An L2TP implementation 3111 MAY provide an option to disable UDP checksums for data messages. It 3112 is recommended that UDP checksums always be enabled on control 3113 packets. 3115 Port 1701 is used for both L2F [RFC2341] and L2TP packets. The 3116 Version field in each header may be used to discriminate between the 3117 two packet types (L2F uses a value of 1, and the L2TP version 3118 described in this document uses a value of 2). An L2TP implementation 3119 running on a system which does not support L2F MUST silently discard 3120 all L2F packets. 3122 To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP link has 3123 the characteristic of being able to reorder or silently drop packets. 3124 The former may break non-IP protocols being carried by PPP, 3125 especially LAN-centric ones such as bridging. The latter may break 3126 protocols which assume per-packet indication of error, such as TCP 3127 header compression. Sequencing may be handled by using L2TP data 3128 message sequence numbers if any protocol being transported by the PPP 3129 tunnel cannot tolerate reordering. The sequence dependency 3130 characteristics of individual protocols are outside the scope of this 3131 document. 3133 Allowing packets to be dropped silently is perhaps more problematic 3134 with some protocols. If PPP reliable delivery [RFC1663] is enabled, 3135 no upper PPP protocol will encounter lost packets. If L2TP sequence 3136 numbers are enabled, L2TP can detect the packet loss. In the case of 3137 an LNS, the PPP and L2TP stacks are both present within the LNS, and 3138 packet loss signaling may occur precisely as if a packet was received 3139 with a CRC error. Where the LAC and PPP stack are co-resident, this 3140 technique also applies. Where the LAC and PPP client are physically 3141 distinct, the analogous signaling MAY be accomplished by sending a 3142 packet with a CRC error to the PPP client. Note that this would 3143 greatly increase the complexity of debugging client line problems, 3144 since the client statistics could not distinguish between true media 3145 errors and LAC-initiated ones. Further, this technique is not 3146 possible on all hardware. 3148 If VJ compression is used, and neither PPP reliable delivery nor 3149 sequence numbers are enabled, each lost packet results in a 1 in 3150 2**16 chance of a TCP segment being forwarded with incorrect contents 3151 [RFC1144]. Where the combination of the packet loss rate with this 3152 statistical exposure is unacceptable, TCP header compression SHOULD 3153 NOT be used. 3155 In general, it is wise to remember that the L2TP/UDP/IP transport is 3156 an unreliable transport. As with any PPP media that is subject to 3157 loss, care should be taken when using protocols that are particularly 3158 loss-sensitive. Such protocols include compression and encryption 3159 protocols that employ history. 3161 8.2 IP 3163 When operating in IP environments, L2TP MUST offer the UDP 3164 encapsulation described in 8.1 as its default configuration for IP 3165 operation. Other configurations (perhaps corresponding to a 3166 compressed header format) MAY be defined and made available as a 3167 configurable option. 3169 9.0 Security Considerations 3171 L2TP encounters several security issues in its operation. The 3172 general approach of L2TP to these issues is documented here. 3174 9.1 Tunnel Endpoint Security 3176 The tunnel endpoints may optionally perform an authentication 3177 procedure of one another during tunnel establishment. This 3178 authentication has the same security attributes as CHAP, and has 3179 reasonable protection against replay and snooping during the tunnel 3180 establishment process. This mechanism is not designed to provide any 3181 authentication beyond tunnel establishment; it is fairly simple for a 3182 malicious user who can snoop the tunnel stream to inject packets once 3183 an authenticated tunnel establishment has been completed 3184 successfully. 3186 For authentication to occur, the LAC and LNS MUST share a single 3187 secret. Each side uses this same secret when acting as authenticatee 3188 as well as authenticator. Since a single secret is used, the tunnel 3189 authentication AVPs include differentiating values in the CHAP ID 3190 fields for each message digest calculation to guard against replay 3191 attacks. 3193 The Assigned Tunnel ID and Assigned Session ID (See section 4.4.3) 3194 SHOULD be selected in an unpredictable manner rather than 3195 sequentially or otherwise. Doing so will help deter hijacking of a 3196 session by a malicious user who does not have access to packet traces 3197 between the LAC and LNS. 3199 9.2 Packet Level Security 3201 Securing L2TP requires that the underlying transport make available 3202 encryption, integrity and authentication services for all L2TP 3203 traffic. This secure transport operates on the entire L2TP packet 3204 and is functionally independent of PPP and the protocol being carried 3205 by PPP. As such, L2TP is only concerned with confidentiality, 3206 authenticity, and integrity of the L2TP packets between its tunnel 3207 endpoints (the LAC and LNS), not unlike link-layer encryption being 3208 concerned only about protecting the confidentiality of traffic 3209 between its physical endpoints. 3211 9.3 End to End Security 3213 Protecting the L2TP packet stream via a secure transport does, in 3214 turn, also protect the data within the tunneled PPP packets while 3215 transported from the LAC to the LNS. Such protection should not be 3216 considered a substitution for end-to-end security between 3217 communicating hosts or applications. 3219 9.4 L2TP and IPsec 3221 When running over IP, IPsec provides packet-level security via ESP 3222 and/or AH. All L2TP control and data packets for a particular tunnel 3223 appear as homogeneous UDP/IP data packets to the IPsec system. 3225 In addition to IP transport security, IPsec defines a mode of 3226 operation that allows tunneling of IP packets. The packet level 3227 encryption and authentication provided by IPsec tunnel mode and that 3228 provided by L2TP secured with IPsec provide an equivalent level of 3229 security for these requirements. 3231 IPsec also defines access control features that are required of a 3232 compliant IPsec implementation. These features allow filtering of 3233 packets based upon network and transport layer characteristics such 3234 as IP address, ports, etc. In the L2TP tunneling model, analogous 3235 filtering is logically performed at the PPP layer or network layer 3236 above L2TP. These network layer access control features may be 3237 handled at the LNS via vendor-specific authorization features based 3238 upon the authenticated PPP user, or at the network layer itself by 3239 using IPsec transport mode end-to-end between the communicating 3240 hosts. The requirements for access control mechanisms are not a part 3241 of the L2TP specification and as such are outside the scope of this 3242 document. 3244 9.5 Proxy PPP Authentication 3246 L2TP defines AVPs that MAY be exchanged during session establishment 3247 to provide forwarding of PPP authentication information obtained at 3248 the LAC to the LNS for validation (see section 4.4.5). This implies a 3249 direct trust relationship of the LAC on behalf of the LNS. If the LNS 3250 chooses to implement proxy authentication, it MUST be able to be 3251 configured off, requiring a new round a PPP authentication initiated 3252 by the LNS (which may or may not include a new round of LCP 3253 negotiation). 3255 10.0 IANA Considerations 3257 This document defines a number of "magic" numbers to be maintained by 3258 the IANA. This section explains the criteria to be used by the IANA 3259 to assign additional numbers in each of these lists. The following 3260 subsections describe the assignment policy for the namespaces defined 3261 elsewhere in this document. 3263 10.1 AVP Attributes 3265 As defined in section 4.1, AVPs contain vendor ID, Attribute and 3266 Value fields. For vendor ID value of 0, IANA will maintain a registry 3267 of assigned Attributes and in some case also values. Attributes 0-39 3268 are assigned as defined in section 4.4. The remaining values are 3269 available for assignment upon Expert Review [RFC 2434]. 3271 10.2 Message Type AVP Values 3273 As defined in section 4.4.1, Message Type AVPs (Attribute Type 0) 3274 have an associated value maintained by IANA. Values 0-16 are defined 3275 in section 3.2, the remaining values are available for assignment 3276 upon Expert Review [RFC 2434] 3278 10.3 Result Code AVP Values 3280 As defined in section 4.4.2, Result Code AVPs (Attribute Type 1) 3281 contain three fields. Two of these fields (the Result Code and Error 3282 Code fields) have associated values maintained by IANA. 3284 10.3.1 Result Code Field Values 3286 The Result Code AVP may be included in CDN and StopCCN messages. The 3287 allowable values for the Result Code field of the AVP differ 3288 depending upon the value of the Message Type AVP. For the StopCCN 3289 message, values 0-7 are defined in section 4.4.2; for the CDN 3290 message, values 0-11 are defined in the same section. The remaining 3291 values of the Result Code field for both messages are available for 3292 assignment upon Expert Review [RFC 2434]. 3294 10.3.2 Error Code Field Values 3296 Values 0-7 are defined in section 4.4.2. Remaining values are 3297 available for assignment upon Expert Review [RFC 2434]. 3299 10.4 Framing Capabilities & Bearer Capabilities 3301 The Framing Capabilities AVP and Bearer Capabilities AVPs (defined in 3302 section 4.4.3) both contain 32-bit bitmasks. Additional bits should 3303 only be defined via a Standards Action [RFC 2434]. 3305 10.5 Proxy Authen Type AVP Values 3307 The Proxy Authen Type AVP (Attribute Type 29) has an associated value 3308 maintained by IANA. Values 0-5 are defined in section 4.4.5, the 3309 remaining values are available for assignment upon Expert Review [RFC 3310 2434]. 3312 10.6 AVP Header Bits 3314 There are four remaining reserved bits in the AVP header. Additional 3315 bits should only be assigned via a Standards Action [RFC 2434]. 3317 11.0 References 3319 [DSS1] ITU-T Recommendation, "Digital subscriber Signaling System 3320 No. 1 (DSS 1) - ISDN user-network interface layer 3 3321 specification for basic call control", Rec. Q.931(I.451), 3322 May 1998 3324 [KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network 3325 Security: Private Communications in a Public World", 3326 Prentice Hall, March 1995, ISBN 0-13-061466-1 3328 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 3329 1981. 3331 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 3332 STD 13, RFC 1034, November 1987. 3334 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed 3335 Serial Links", RFC 1144, February 1990. 3337 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 3338 RFC 1661, July 1994. 3340 [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, 3341 July 1994. 3343 [RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994. 3345 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 3346 1700, October 1994. See also: 3347 http://www.iana.org/numbers.html 3349 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. 3350 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, 3351 August 1996. 3353 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 3354 Protocol (CHAP)", RFC 1994, August 1996. 3356 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 3357 and E. Lear, "Address Allocation for Private Internets", 3358 BCP 5, RFC 1918, February 1996. 3360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3361 Requirement Levels", BCP 14, RFC 2119, March 1997. 3363 [RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 3364 Authentication Dial In User Service (RADIUS)", RFC 2138, 3365 April 1997. 3367 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 3368 Languages", BCP 18, RFC 2277, January 1998. 3370 [RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two 3371 Forwarding (Protocol) L2F", RFC 2341, May 1998. 3373 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 3374 Internet Protocol", RFC 2401, November 1998. 3376 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3377 IANA Considerations section in RFCs", BCP 26, RFC 2434, 3378 October 1998. 3380 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. 3381 and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", 3382 RFC 2637, July 1999. 3384 [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I The 3385 Protocols", Addison-Wesley Publishing Company, Inc., March 3386 1996, ISBN 0-201-63346-9 3388 12.0 Acknowledgments 3390 The basic concept for L2TP and many of its protocol constructs were 3391 adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these are 3392 A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. 3393 Verthein, J. Taarud, W. Little, and G. Zorn. 3395 Dory Leifer made valuable refinements to the protocol definition of 3396 L2TP and contributed to the editing of this document. 3398 Steve Cobb and Evan Caves redesigned the state machine tables. 3400 Barney Wolff provided a great deal of design input on the endpoint 3401 authentication mechanism. 3403 John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, 3404 Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and 3405 review at the 43rd IETF in Orlando, FL., which led to improvement of 3406 the overall readability and clarity of this document. 3408 13.0 Authors' Addresses 3410 Gurdeep Singh Pall 3411 Microsoft Corporation 3412 Redmond, WA 3414 Email: gurdeep@microsoft.com 3416 Bill Palter 3417 RedBack Networks, Inc 3418 1389 Moffett Park Drive 3419 Sunnyvale, CA 94089 3421 Email: palter@zev.net 3423 Allan Rubens 3425 Email: acr@del.com 3427 W. Mark Townsley 3428 cisco Systems 3429 7025 Kit Creek Road 3430 PO Box 14987 3431 Research Triangle Park, NC 27709 3433 Email: mark@townsley.net 3435 Andrew J. Valencia 3436 P.O. Box 2928 3437 Vashon, WA 98070 3439 Email: vandys@zendo.com 3441 Glen Zorn 3442 cisco Systems 3443 500 108th Avenue N.E., Suite 500 3444 Bellevue, WA 98004 3446 Email: gwz@cisco.com 3448 Appendix A: Control Channel Slow Start and Congestion Avoidance 3450 Although each side has indicated the maximum size of its receive 3451 window, it is recommended that a slow start and congestion avoidance 3452 method be used to transmit control packets. The methods described 3453 here are based upon the TCP congestion avoidance algorithm as 3454 described in section 21.6 of TCP/IP Illustrated, Volume I, by W. 3455 Richard Stevens [STEVENS]. 3457 Slow start and congestion avoidance make use of several variables. 3458 The congestion window (CWND) defines the number of packets a sender 3459 may send before waiting for an acknowledgment. The size of CWND 3460 expands and contracts as described below. Note however, that CWND is 3461 never allowed to exceed the size of the advertised window obtained 3462 from the Receive Window AVP (in the text below, it is assumed any 3463 increase will be limited by the Receive Window Size). The variable 3464 SSTHRESH determines when the sender switches from slow start to 3465 congestion avoidance. Slow start is used while CWND is less than 3466 SSHTRESH. 3468 A sender starts out in the slow start phase. CWND is initialized to 3469 one packet, and SSHTRESH is initialized to the advertised window 3470 (obtained from the Receive Window AVP). The sender then transmits 3471 one packet and waits for its acknowledgement (either explicit or 3472 piggybacked). When the acknowledgement is received, the congestion 3473 window is incremented from one to two. During slow start, CWND is 3474 increased by one packet each time an ACK (explicit ZLB or 3475 piggybacked) is received. Increasing CWND by one on each ACK has the 3476 effect of doubling CWND with each round trip, resulting in an 3477 exponential increase. When the value of CWND reaches SSHTRESH, the 3478 slow start phase ends and the congestion avoidance phase begins. 3480 During congestion avoidance, CWND expands more slowly. Specifically, 3481 it increases by 1/CWND for every new ACK received. That is, CWND is 3482 increased by one packet after CWND new ACKs have been received. 3483 Window expansion during the congestion avoidance phase is effectively 3484 linear, with CWND increasing by one packet each round trip. 3486 When congestion occurs (indicated by the triggering of a 3487 retransmission) one half of the CWND is saved in SSTHRESH, and CWND 3488 is set to one. The sender then reenters the slow start phase. 3490 Appendix B: Control Message Examples 3492 B.1: Lock-step tunnel establishment 3494 In this example, an LAC establishes a tunnel, with the exchange 3495 involving each side alternating in sending messages. This example 3496 shows the final acknowledgment explicitly sent within a ZLB ACK 3497 message. An alternative would be to piggyback the acknowledgement 3498 within a message sent as a reply to the ICRQ or OCRQ that will 3499 likely follow from the side that initiated the tunnel. 3501 LAC or LNS LNS or LAC 3502 ---------- ---------- 3504 SCCRQ -> 3505 Nr: 0, Ns: 0 3506 <- SCCRP 3507 Nr: 1, Ns: 0 3508 SCCCN -> 3509 Nr: 1, Ns: 1 3510 <- ZLB 3511 Nr: 2, Ns: 1 3513 B.2: Lost packet with retransmission 3515 An existing tunnel has a new session requested by the LAC. The ICRP 3516 is lost and must be retransmitted by the LNS. Note that loss of the 3517 ICRP has two impacts: not only does it keep the upper level state 3518 machine from progressing, but it also keeps the LAC from seeing a 3519 timely lower level acknowledgment of its ICRQ. 3521 LAC LNS 3522 --- --- 3524 ICRQ -> 3525 Nr: 1, Ns: 2 3527 (packet lost) <- ICRP 3528 Nr: 3, Ns: 1 3530 (pause; LAC's timer started first, so fires first) 3532 ICRQ -> 3533 Nr: 1, Ns: 2 3535 (Realizing that it has already seen this packet, 3536 the LNS discards the packet and sends a ZLB) 3538 <- ZLB 3539 Nr: 3, Ns: 2 3541 (LNS's retransmit timer fires) 3543 <- ICRP 3544 Nr: 3, Ns: 1 3545 ICCN -> 3546 Nr: 2, Ns: 3 3548 <- ZLB 3549 Nr: 4, Ns: 2 3551 Appendix C: Intellectual Property Notice 3553 The IETF takes no position regarding the validity or scope of any 3554 intellectual property or other rights that might be claimed to 3555 pertain to the implementation or use of the technology described in 3556 this document or the extent to which any license under such rights 3557 might or might not be available; neither does it represent that it 3558 has made any effort to identify any such rights. Information on the 3559 IETF's procedures with respect to rights in standards-track and 3560 standards-related documentation can be found in BCP-11. Copies of 3561 claims of rights made available for publication and any assurances of 3562 licenses to be made available, or the result of an attempt made to 3563 obtain a general license or permission for the use of such 3564 proprietary rights by implementers or users of this specification can 3565 be obtained from the IETF Secretariat." 3567 The IETF invites any interested party to bring to its attention any 3568 copyrights, patents or patent applications, or other proprietary 3569 rights which may cover technology that may be required to practice 3570 this standard. Please address the information to the IETF Executive 3571 Director. 3573 The IETF has been notified of intellectual property rights claimed in 3574 regard to some or all of the specification contained in this 3575 document. For more information consult the online list of claimed 3576 rights.