idnits 2.17.1 draft-ietf-pppext-l2tp-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == It seems as if not all pages are separated by form feeds - found 0 form feeds but 75 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 14 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC1661]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2701 has weird spacing: '...e local wai...' == Line 2702 has weird spacing: '...ndicate tunne...' == Line 2911 has weird spacing: '...e local wai...' == Line 3150 has weird spacing: '...hat are requi...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1999) is 9074 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 342, but not defined == Missing Reference: 'System' is mentioned on line 342, but not defined == Missing Reference: 'KPS' is mentioned on line 708, but not defined == Missing Reference: 'DSS1' is mentioned on line 1208, but not defined == Missing Reference: 'Remote' is mentioned on line 1867, but not defined == Missing Reference: 'RFC 2434' is mentioned on line 3236, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Missing Reference: 'PPTP' is mentioned on line 3322, but not defined == Unused Reference: 'RFC791' is defined on line 3252, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 3286, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 3306, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 3310, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2138 (Obsoleted by RFC 2865) ** Downref: Normative reference to an Historic RFC: RFC 2341 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. 'STEVENS' Summary: 12 errors (**), 0 flaws (~~), 17 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W. M. Townsley 2 Internet-Draft A. Valencia 3 Category: Standards Track cisco Systems 4 A. Rubens 5 Ascend Communications 6 G. S. Pall 7 G. Zorn 8 Microsoft Corporation 9 B. Palter 10 Redback Networks 11 June 1999 13 Layer Two Tunneling Protocol "L2TP" 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress''. 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 To learn the current status of any Internet-Draft, please check the 37 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 38 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 39 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 41 The distribution of this memo is unlimited. It is filed as and expires December 31, 1999. Please send 43 comments to the L2TP mailing list (l2tp@ipsec.org). 45 Copyright Notice 47 Copyright (C) The Internet Society (1999). All Rights Reserved. 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........................................ 14 70 4.3 Hiding of AVP Attribute Values........................ 15 71 4.4 AVP Summary........................................... 17 72 5.0 Protocol Operation.................................... 40 73 5.1 Control Connection Establishment...................... 41 74 5.2 Session Establishment................................. 42 75 5.3 Forwarding PPP Frames................................. 43 76 5.4 Using Sequence Numbers on the Data Channel............ 43 77 5.5 Keepalive (Hello)..................................... 44 78 5.6 Session Teardown...................................... 45 79 5.7 Control Connection Teardown........................... 45 80 5.8 Reliable Delivery of Control Messages................. 45 81 6.0 Control Connection Protocol Specification............. 47 82 6.1 Start-Control-Connection-Request (SCCRQ).............. 48 83 6.2 Start-Control-Connection-Reply (SCCRP)................ 48 84 6.3 Start-Control-Connection-Connected (SCCCN)............ 49 85 6.4 Stop-Control-Connection-Notification (StopCCN)........ 49 86 6.5 Hello (HELLO)......................................... 49 87 6.6 Incoming-Call-Request (ICRQ).......................... 50 88 6.7 Incoming-Call-Reply (ICRP)............................ 51 89 6.8 Incoming-Call-Connected (ICCN)........................ 51 90 6.9 Outgoing-Call-Request (OCRQ).......................... 52 91 6.10 Outgoing-Call-Reply (OCRP)........................... 52 92 6.11 Outgoing-Call-Connected (OCCN)....................... 53 93 6.12 Call-Disconnect-Notify (CDN)......................... 53 94 6.13 WAN-Error-Notify (WEN)............................... 53 95 6.14 Set-Link-Info (SLI).................................. 54 96 7.0 Control Connection State Machines..................... 54 97 7.1 Control Connection Protocol Operation................. 54 98 7.2 Control Connection States............................. 55 99 7.2.1 Control Connection Establishment................. 55 100 7.3 Timing considerations................................. 57 101 7.4 Incoming calls........................................ 58 102 7.4.1 LAC Incoming Call States......................... 58 103 7.4.2 LNS Incoming Call States......................... 60 104 7.5 Outgoing calls........................................ 61 105 7.5.1 LAC Outgoing Call States......................... 62 106 7.5.2 LNS Outgoing Call States......................... 63 107 7.6 Tunnel Disconnection.................................. 64 108 8.0 L2TP Over Specific Media.............................. 65 109 8.1 L2TP over UDP/IP...................................... 65 110 8.2 IP.................................................... 66 111 9.0 Security Considerations............................... 67 112 9.1 Tunnel Endpoint Security.............................. 67 113 9.2 Packet Level Security................................. 67 114 9.3 End to End Security................................... 67 115 9.4 L2TP and IPsec........................................ 68 116 9.5 Proxy PPP Authentication.............................. 68 117 10.0 IANA Considerations.................................. 68 118 10.1 AVP Attributes....................................... 69 119 10.2 Message Type AVP Values.............................. 69 120 10.3 Result Code AVP Values............................... 69 121 10.3.1 Result Code Field Values........................ 69 122 10.3.2 Error Code Field Values......................... 69 123 10.4 Framing Capabilities & Bearer Capabilities........... 69 124 10.5 Proxy Authen Type AVP Values......................... 69 125 10.6 AVP Header Bits...................................... 70 126 11.0 References........................................... 70 127 12.0 Acknowledgments...................................... 71 128 13.0 Author's Addresses................................... 72 130 Appendix A: Control Channel Slow Start and Congestion Avoidance 73 132 Appendix B: Control Message Examples......................... 73 134 Appendix C: Intellectual Property Notice..................... 75 136 1.0 Introduction 138 PPP [RFC1661] defines an encapsulation mechanism for transporting 139 multiprotocol packets across layer 2 (L2) point-to-point links. 140 Typically, a user obtains a L2 connection to a Network Access Server 141 (NAS) using one of a number of techniques (e.g., dialup POTS, ISDN, 142 ADSL, etc.) and then runs PPP over that connection. In such a 143 configuration, the L2 termination point and PPP session endpoint 144 reside on the same physical device (i.e., the NAS). 146 L2TP extends the PPP model by allowing the L2 and PPP endpoints to 147 reside on different devices interconnected by a packet-switched 148 network. With L2TP, a user has an L2 connection to an access 149 concentrator (e.g., modem bank, ADSL DSLAM, etc.), and the 150 concentrator then tunnels individual PPP frames to the NAS. This 151 allows the actual processing of PPP packets to be divorced from the 152 termination of the L2 circuit. 154 One obvious benefit of such a separation is that instead of requiring 155 the L2 connection terminate at the NAS (which may require a long- 156 distance toll charge), the connection may terminate at a (local) 157 circuit concentrator, which then extends the logical PPP session over 158 a shared infrastructure such as frame relay circuit or the Internet. 159 From the user's perspective, there is no functional difference 160 between having the L2 circuit terminate in a NAS directly or using 161 L2TP. 163 L2TP may also solve the multilink hunt-group splitting problem. 164 Multilink PPP [RFC1990] requires that all channels composing a 165 multilink bundle be grouped at a single Network Access Server (NAS). 166 Due to its ability to project a PPP session to a location other than 167 the point at which it was physically received, L2TP can be used to 168 make all channels terminate at a single NAS. This allows multilink 169 operation even when the calls are spread across distinct physical 170 NASs. 172 This document defines the necessary control protocol for on-demand 173 creation of tunnels between two nodes and the accompanying 174 encapsulation for multiplexing multiple, tunneled PPP sessions. 176 1.1 Specification of Requirements 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 1.2 Terminology 184 Analog Channel 186 A circuit-switched communication path which is intended to carry 187 3.1 kHz audio in each direction. 189 Attribute Value Pair (AVP) 191 The variable length concatenation of a unique Attribute 192 (represented by an integer) and a Value containing the actual 193 value identified by the attribute. Multiple AVPs make up Control 194 Messages which are used in the establishment, maintenance, and 195 teardown of tunnels. 197 Call 199 A connection (or attempted connection) between a Remote System and 200 LAC. For example, a telephone call through the PSTN. A Call 201 (Incoming or Outgoing) which is successfully established between a 202 Remote System and LAC results in a corresponding L2TP Session 203 within a previously established Tunnel between the LAC and LNS. 204 (See also: Session, Incoming Call, Outgoing Call). 206 Called Number 208 An indication to the receiver of a call as to what telephone 209 number the caller used to reach it. 211 Calling Number 213 An indication to the receiver of a call as to the telephone number 214 of the caller. 216 CHAP 218 Challenge Handshake Authentication Protocol [RFC1994], a PPP 219 cryptographic challenge/response authentication protocol in which 220 the cleartext password is not passed over the line. 222 Control Connection 224 A control connection operates in-band over a tunnel to control the 225 establishment, release, and maintenance of sessions and of the 226 tunnel itself. 228 Control Messages 230 Control messages are exchanged between LAC and LNS pairs, 231 operating in-band within the tunnel protocol. Control messages 232 govern aspects of the tunnel and sessions within the tunnel. 234 Digital Channel 236 A circuit-switched communication path which is intended to carry 237 digital information in each direction. 239 DSLAM 241 Digital Subscriber Line (DSL) Access Module. A network device used 242 in the deployment of DSL service. This is typically a concentrator 243 of individual DSL lines located in a central office (CO) or local 244 exchange. 246 Incoming Call 248 A Call received at an LAC to be tunneled to an LNS (see Call, 249 Outgoing Call). 251 L2TP Access Concentrator (LAC) 253 A node that acts as one side of an L2TP tunnel endpoint and is a 254 peer to the L2TP Network Server (LNS). The LAC sits between an 255 LNS and a remote system and forwards packets to and from each. 256 Packets sent from the LAC to the LNS requires tunneling with the 257 L2TP protocol as defined in this document. The connection from 258 the LAC to the remote system is either local (see: Client LAC) or 259 a PPP link. 261 L2TP Network Server (LNS) 263 A node that acts as one side of an L2TP tunnel endpoint and is a 264 peer to the L2TP Access Concentrator (LAC). The LNS is the 265 logical termination point of a PPP session that is being tunneled 266 from the remote system by the LAC. 268 Management Domain (MD) 270 A network or networks under the control of a single 271 administration, policy or system. For example, an LNS's Management 272 Domain might be the corporate network it serves. An LAC's 273 Management Domain might be the Internet Service Provider that owns 274 and manages it. 276 Network Access Server (NAS) 278 A device providing local network access to users across a remote 279 access network such as the PSTN. An NAS may also serve as an LAC, 280 LNS or both. 282 Outgoing Call 284 A Call placed by an LAC on behalf of an LNS (see Call, Incoming 285 Call). 287 Peer 289 When used in context with L2TP, peer refers to either the LAC or 290 LNS. An LAC's Peer is an LNS and vice versa. When used in context 291 with PPP, a peer is either side of the PPP connection. 293 POTS 295 Plain Old Telephone Service. 297 Remote System 298 An end-system or router attached to a remote access network (i.e. 299 a PSTN), which is either the initiator or recipient of a call. 300 Also referred to as a dial-up or virtual dial-up client. 302 Session 304 L2TP is connection-oriented. The LNS and LAC maintain state for 305 each Call that is initiated or answered by an LAC. An L2TP Session 306 is created between the LAC and LNS when an end-to-end PPP 307 connection is established between a Remote System and the LNS. 308 Datagrams related to the PPP connection are sent over the Tunnel 309 between the LAC and LNS. There is a one to one relationship 310 between established L2TP Sessions and their associated Calls. (See 311 also: Call). 313 Tunnel 315 A Tunnel exists between a LAC-LNS pair. The Tunnel consists of a 316 Control Connection and zero or more L2TP Sessions. The Tunnel 317 carries encapsulated PPP datagrams and Control Messages between 318 the LAC and the LNS. 320 Zero-Length Body (ZLB) Message 322 A control packet with only an L2TP header. ZLB messages are used 323 for explicitly acknowledging packets on the reliable control 324 channel. 326 2.0 Topology 328 The following diagram depicts a typical L2TP scenario. The goal is to 329 tunnel PPP frames between the Remote System or LAC Client and an LNS 330 located at a Home LAN. 332 [Home LAN] 333 [LAC Client]----------+ | 334 ____|_____ +--[Host] 335 | | | 336 [LAC]---------| Internet |-----[LNS]-----+ 337 | |__________| | 338 _____|_____ : 339 | | 340 | PSTN | 341 [Remote]--| Cloud | 342 [System] | | [Home LAN] 343 |___________| | 344 | ______________ +---[Host] 345 | | | | 346 [LAC]-------| Frame Relay |---[LNS]-----+ 347 | or ATM Cloud | | 348 |______________| : 350 The Remote System initiates a PPP connection across the PSTN Cloud to 351 an LAC. The LAC then tunnels the PPP connection across the Internet, 352 Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN is 353 obtained. The Remote System is provided addresses from the HOME LAN 354 via PPP NCP negotiation. Authentication, Authorization and Accounting 355 may be provided by the Home LAN's Management Domain as if the user 356 were connected to a Network Access Server directly. 358 A LAC Client (a Host which runs L2TP natively) may also participate 359 in tunneling to the Home LAN without use of a separate LAC. In this 360 case, the Host containing the LAC Client software already has a 361 connection to the public Internet. A "virtual" PPP connection is then 362 created and the local L2TP LAC Client software creates a tunnel to 363 the LNS. As in the above case, Addressing, Authentication, 364 Authorization and Accounting will be provided by the Home LAN's 365 Management Domain. 367 3.0 Protocol Overview 369 L2TP utilizes two types of messages, control messages and data 370 messages. Control messages are used in the establishment, maintenance 371 and clearing of tunnels and calls. Data messages are used to 372 encapsulate PPP frames being carried over the tunnel. Control 373 messages utilize a reliable Control Channel within L2TP to guarantee 374 delivery (see section 5.1 for details). Data messages are not 375 retransmitted when packet loss occurs. 377 +-------------------+ 378 | PPP Frames | 379 +-------------------+ +-----------------------+ 380 | L2TP Data Messages| | L2TP Control Messages | 381 +-------------------+ +-----------------------+ 382 | L2TP Data Channel | | L2TP Control Channel | 383 | (unreliable) | | (reliable) | 384 +------------------------------------------------+ 385 | Packet Transport (UDP, FR, ATM, etc.) | 386 +------------------------------------------------+ 388 Figure 3.0 L2TP Protocol Structure 390 Figure 3.0 depicts the relationship of PPP frames and Control 391 Messages over the L2TP Control and Data Channels. PPP Frames are 392 passed over an unreliable Data Channel encapsulated first by an L2TP 393 header and then a Packet Transport such as UDP, Frame Relay, ATM, 394 etc. Control messages are sent over a reliable L2TP Control Channel 395 which transmits packets in-band over the same Packet Transport. 397 Sequence numbers are required to be present in all control messages 398 and are used to provide reliable delivery on the Control Channel. 399 Data Messages may use sequence numbers to reorder packets and detect 400 lost packets. 402 All values are placed into their respective fields and sent in 403 network order (high order octets first). 405 3.1 L2TP Header Format 407 L2TP packets for the control channel and data channel share a common 408 header format. In each case where a field is optional, its space does 409 not exist in the message if the field is marked not present. Note 410 that while optional on data messages, the Length, Ns, and Nr fields 411 marked as optional below, are required to be present on all control 412 messages. 414 This header is formatted: 416 0 1 2 3 417 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Tunnel ID | Session ID | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Ns (opt) | Nr (opt) | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Offset Size (opt) | Offset pad... (opt) 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Figure 3.1 L2TP Message Header 430 The Type (T) bit indicates the type of message. It is set to 0 for a 431 data message and 1 for a control message. 433 If the Length (L) bit is 1, the Length field is present. This bit 434 MUST be set to 1 for control messages. 436 The x bits are reserved for future extensions. All reserved bits MUST 437 be set to 0 on outgoing messages and ignored on incoming messages. 439 If the Sequence (S) bit is set to 1 the Ns and Nr fields are present. 440 The S bit MUST be set to 1 for control messages. 442 If the Offset (O) bit is 1, the Offset Size field is present. The O 443 bit MUST be set to 0 (zero) for control messages. 445 If the Priority (P) bit is 1, this data message should receive 446 preferential treatment in its local queuing and transmission. LCP 447 echo requests used as a keepalive for the link, for instance, should 448 generally be sent with this bit set to 1. Without it, a temporary 449 interval of local congestion could result in interference with 450 keepalive messages and unnecessary loss of the link. This feature is 451 only for use with data messages. The P bit MUST be set to 0 for all 452 control messages. 454 Ver MUST be 2, indicating the version of the L2TP data message header 455 described in this document. The value 1 is reserved to permit 456 detection of L2F [RFC2341] packets should they arrive intermixed with 457 L2TP packets. Packets received with an unknown Ver field MUST be 458 discarded. 460 The Length field indicates the total length of the message in octets. 462 Tunnel ID indicates the identifier for the control connection. L2TP 463 tunnels are named by identifiers that have local significance only. 464 That is, the same tunnel will be given different Tunnel IDs by each 465 end of the tunnel. Tunnel ID in each message is that of the intended 466 recipient, not the sender. Tunnel IDs are selected and exchanged as 467 Assigned Tunnel ID AVPs during the creation of a tunnel. 469 Session ID indicates the identifier for a session within a tunnel. 470 L2TP sessions are named by identifiers that have local significance 471 only. That is, the same session will be given different Session IDs 472 by each end of the session. Session ID in each message is that of the 473 intended recipient, not the sender. Session IDs are selected and 474 exchanged as Assigned Session ID AVPs during the creation of a 475 session. 477 Ns indicates the sequence number for this data or control message, 478 beginning at zero and incrementing by one (modulo 2**16) for each 479 message sent. See Section 5.8 and 5.4 for more information on using 480 this field. 482 Nr indicates the sequence number expected in the next control message 483 to be received. Thus, Nr is set to the Ns of the last in-order 484 message received plus one (modulo 2**16). In data messages, Nr is 485 reserved and, if present (as indicated by the S-bit), MUST be ignored 486 upon receipt. See section 5.8 for more information on using this 487 field in control messages. 489 The Offset Size field, if present, specifies the number of octets 490 past the L2TP header at which the payload data is expected to start. 491 Actual data within the offset padding is undefined. If the offset 492 field is present, the L2TP header ends after the last octet of the 493 offset padding. 495 3.2 Control Message Types 497 The Message Type AVP (see section 4.4.1) defines the specific type of 498 control message being sent. Recall from section 3.1 that this is only 499 for control messages, that is, messages with the T-bit set to 1. 501 This document defines the following control message types (see 502 Section 6.1 through 6.14 for details on the construction and use of 503 each message): 505 Control Connection Management 507 0 (reserved) 509 1 (SCCRQ) Start-Control-Connection-Request 510 2 (SCCRP) Start-Control-Connection-Reply 511 3 (SCCCN) Start-Control-Connection-Connected 512 4 (StopCCN) Stop-Control-Connection-Notification 513 5 (reserved) 514 6 (HELLO) Hello 516 Call Management 518 7 (OCRQ) Outgoing-Call-Request 519 8 (OCRP) Outgoing-Call-Reply 520 9 (OCCN) Outgoing-Call-Connected 521 10 (ICRQ) Incoming-Call-Request 522 11 (ICRP) Incoming-Call-Reply 523 12 (ICCN) Incoming-Call-Connected 524 13 (reserved) 525 14 (CDN) Call-Disconnect-Notify 527 Error Reporting 529 15 (WEN) WAN-Error-Notify 531 PPP Session Control 533 16 (SLI) Set-Link-Info 535 4.0 Control Message Attribute Value Pairs 537 To maximize extensibility while still permitting interoperability, a 538 uniform method for encoding message types and bodies is used 539 throughout L2TP. This encoding will be termed AVP (Attribute-Value 540 Pair) in the remainder of this document. 542 4.1 AVP Format 544 Each AVP is encoded as: 546 0 1 2 3 547 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 |M|H| rsvd | Length | Vendor ID | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Attribute Type | Attribute Value... 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 [until Length is reached]... | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 The first six bits are a bit mask, describing the general attributes 557 of the AVP. 559 Two bits are defined in this document, the remaining are reserved for 560 future extensions. Reserved bits MUST be set to 0. An AVP received 561 with a reserved bit set to 1 MUST be treated as an unrecognized AVP. 563 Mandatory (M) bit: Controls the behavior required of an 564 implementation which receives an AVP which it does not recognize. If 565 the M bit is set on an unrecognized AVP within a message associated 566 with a particular session, the session associated with this message 567 MUST be terminated. If the M bit is set on an unrecognized AVP within 568 a message associated with the overall tunnel, the entire tunnel (and 569 all sessions within) MUST be terminated. If the M bit is not set, an 570 unrecognized AVP MUST be ignored. The control message must then 571 continue to be processed as if the AVP had not been present. 573 Hidden (H) bit: Identifies the hiding of data in the Attribute Value 574 field of an AVP. This capability can be used to avoid the passing of 575 sensitive data, such as user passwords, as cleartext in an AVP. 576 Section 4.3 describes the procedure for performing AVP hiding. 578 Length: Encodes the number of octets (including the Overall Length 579 and bitmask fields) contained in this AVP. The Length may be 580 calculated as 6 + the length of the Attribute Value field in octets. 581 The field itself is 10 bits, permitting a maximum of 1023 octets of 582 data in a single AVP. The minimum Length of an AVP is 6. If the 583 length is 6, then the Attribute Value field is absent. 585 Vendor ID: The IANA assigned "SMI Network Management Private 586 Enterprise Codes" [RFC1700] value. The value 0, corresponding to 587 IETF adopted attribute values, is used for all AVPs defined within 588 this document. Any vendor wishing to implement their own L2TP 589 extensions can use their own Vendor ID along with private Attribute 590 values, guaranteeing that they will not collide with any other 591 vendor's extensions, nor with future IETF extensions. Note that there 592 are 16 bits allocated for the Vendor ID, thus limiting this feature 593 to the first 65,535 enterprises. 595 Attribute Type: A 2 octet value with a unique interpretation across 596 all AVPs defined under a given Vendor ID. 598 Attribute Value: This is the actual value as indicated by the Vendor 599 ID and Attribute Type. It follows immediately after the Attribute 600 Type field, and runs for the remaining octets indicated in the Length 601 (i.e., Length minus 6 octets of header). This field is absent if the 602 Length is 6. 604 4.2 Mandatory AVPs 606 Receipt of an unknown AVP that has the M-bit set is catastrophic to 607 the session or tunnel it is associated with. Thus, the M bit should 608 only be defined for AVPs which are absolutely crucial to proper 609 operation of the session or tunnel. Further, in the case where the 610 LAC or LNS receives an unknown AVP with the M-bit set and shuts down 611 the session or tunnel accordingly, it is the full responsibility of 612 the peer sending the Mandatory AVP to accept fault for causing an 613 non-interoperable situation. Before defining an AVP with the M-bit 614 set, particularly a vendor-specific AVP, be sure that this is the 615 intended consequence. 617 When an adequate alternative exists to use of the M-bit, it should be 618 utilized. For example, rather than simply sending an AVP with the M- 619 bit set to determine if a specific extension exists, availability may 620 be identified by sending an AVP in a request message and expecting a 621 corresponding AVP in a reply message. 623 Use of the M-bit with new AVPs (those not defined in this document) 624 MUST provide the ability to configure the associated feature off, 625 such that the AVP is either not sent, or sent with the M-bit not set. 627 4.3 Hiding of AVP Attribute Values 629 The H bit in the header of each AVP provides a mechanism to indicate 630 to the receiving peer whether the contents of the AVP are hidden or 631 present in cleartext. This feature can be used to hide sensitive 632 control message data such as user passwords or user IDs. 634 The H bit MUST only be set if a shared secret exists between the LAC 635 and LNS. The shared secret is the same secret that is used for tunnel 636 authentication (see Section 5.1.1). If the H bit is set in any 637 AVP(s) in a given control message, a Random Vector AVP must also be 638 present in the message and MUST precede the first AVP having an H bit 639 of 1. 641 Hiding an AVP value is done in several steps. The first step is to 642 take the length and value fields of the original (cleartext) AVP and 643 encode them into a Hidden AVP Subformat as follows: 645 0 1 2 3 646 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Length of Original Value | Original Attribute Value ... 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 ... | Padding ... 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 Length of Original Attribute Value: This is length of the Original 654 Attribute Value to be obscured in octets. This is necessary to 655 determine the original length of the Attribute Value which is lost 656 when the additional Padding is added. 658 Original Attribute Value: Attribute Value that is to be obscured. 660 Padding: Random additional octets used to obscure length of the 661 Attribute Value that is being hidden. 663 To mask the size of the data being hidden, the resulting subformat 664 MAY be padded as shown above. Padding does NOT alter the value placed 665 in the Length of Original Attribute Value field, but does alter the 666 length of the resultant AVP that is being created. For example, If an 667 Attribute Value to be hidden is 4 octets in length, the unhidden AVP 668 length would be 10 octets (6 + Attribute Value length). After hiding, 669 the length of the AVP will become 6 + Attribute Value length + size 670 of the Length of Original Attribute Value field + Padding. Thus, if 671 Padding is 12 octects, the AVP length will be 6 + 4 + 2 + 12 = 24 672 octets. 674 Next, An MD5 hash is performed on the concatenation of: 676 + the 2 octet Attribute number of the AVP 677 + the shared secret 678 + an arbitrary length random vector 680 The value of the random vector used in this hash is passed in the 681 value field of a Random Vector AVP. This Random Vector AVP must be 682 placed in the message by the sender before any hidden AVPs. The same 683 random vector may be used for more than one hidden AVP in the same 684 message. If a different random vector is used for the hiding of 685 subsequent AVPs then a new Random Vector AVP must be placed in the 686 command message before the first AVP to which it applies. 688 The MD5 hash value is then XORed with the first 16 octet (or less) 689 segment of the Hidden AVP Subformat and placed in the Attribute Value 690 field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 691 octets, the Subformat is transformed as if the Attribute Value field 692 had been padded to 16 octets before the XOR, but only the actual 693 octets present in the Subformat are modified, and the length of the 694 AVP is not altered. 696 If the Subformat is longer than 16 octets, a second one-way MD5 hash 697 is calculated over a stream of octets consisting of the shared secret 698 followed by the result of the first XOR. That hash is XORed with the 699 second 16 octet (or less) segment of the Subformat and placed in the 700 corresponding octets of the Value field of the Hidden AVP. 702 If necessary, this operation is repeated, with the shared secret used 703 along with each XOR result to generate the next hash to XOR the next 704 segment of the value with. 706 The hiding method was adapted from RFC 2138 [RFC2138] which was taken 707 from from the "Mixing in the Plaintext" section in the book "Network 708 Security" by Kaufman, Perlman and Speciner [KPS]. A detailed 709 explanation of the method follows: 711 Call the shared secret S, the Random Vector RV, and the Attribute 712 Value AV. Break the value field into 16-octet chunks p1, p2, etc. 714 with the last one padded at the end with random data to a 16-octet 715 boundary. Call the ciphertext blocks c(1), c(2), etc. We will also 716 define intermediate values b1, b2, etc. 718 b1 = MD5(AV + S + RV) c(1) = p1 xor b1 719 b2 = MD5(S + c(1)) c(2) = p2 xor b2 720 . . 721 . . 722 . . 723 bi = MD5(S + c(i-1)) c(i) = pi xor bi 725 The String will contain c(1)+c(2)+...+c(i) where + denotes 726 concatenation. 728 On receipt, the random vector is taken from the last Random Vector 729 AVP encountered in the message prior to the AVP to be unhidden. The 730 above process is then reversed to yield the original value. 732 4.4 AVP Summary 734 The following sections contain a list of all L2TP AVPs defined in 735 this document. 737 Following the name of the AVP is a list indicating the message types 738 that utilize each AVP. After each AVP title follows a short 739 description of the purpose of the AVP, a detail (including a graphic) 740 of the format for the Attribute Value, and any additional information 741 needed for proper use of the avp. 743 4.4.1 AVPs Applicable To All Control Messages 745 Message Type (All Messages) 747 The Message Type AVP, Attribute Type 0, identifies the control 748 message herein and defines the context in which the exact meaning 749 of the following AVPs will be determined. 751 The Attribute Value field for this AVP has the following format: 753 0 1 754 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Message Type | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 The Message Type is a 2 octet unsigned integer. 761 The Message Type AVP MUST be the first AVP in a message, 762 immediately following the control message header (defined in 763 section 3.1). See Section 3.2 for the list of defined control 764 message types and their identifiers. 766 The Mandatory (M) bit within the Message Type AVP has special 767 meaning. Rather than an indication as to whether the AVP itself 768 should be ignored if not recognized, it is an indication as to 769 whether the control message itself should be ignored. Thus, if the 770 M-bit is set within the Message Type AVP and the Message Type is 771 unknown to the implementation, the tunnel MUST be cleared. If the 772 M-bit is not set, then the implementation may ignore an unknown 773 message type. The M-bit MUST be set to 1 for all message types 774 defined in this document. This AVP may not be hidden (the H-bit 775 MUST be 0). The Length of this AVP is 8. 777 Random Vector (All Messages) 779 The Random Vector AVP, Attribute Type 36, is used to enable the 780 hiding of the Attribute Value of arbitrary AVPs. 782 The Attribute Value field for this AVP has the following format: 784 0 1 2 3 785 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Random Octet String ... 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 The Random Octet String may be of arbitrary length, although a 791 random vector of at least 16 octets is recommended. The string 792 contains the random vector for use in computing the MD5 hash to 793 retrieve or hide the Attribute Value of a hidden AVP (see Section 794 4.2). 796 More than one Random Vector AVP may appear in a message, in which 797 case a hidden AVP uses the Random Vector AVP most closely 798 preceeding it. This AVP MUST precede the first AVP with the H bit 799 set. 801 The M-bit for this AVP MUST be set to 1. This AVP MUST NOT be 802 hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the 803 length of the Random Octet String. 805 4.4.2 Result and Error Codes 807 Result Code (CDN, StopCCN) 809 The Result Code AVP, Attribute Type 1, indicates the reason for 810 terminating the control channel or session. 812 The Attribute Value field for this AVP has the following format: 814 0 1 2 3 815 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Result Code | Error Code (opt) | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Error Message (opt) ... 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 The Result Code is a 2 octet unsigned integer. The optional Error 823 Code is a 2 octet unsigned integer. An optional Error Message can 824 follow the Error Code field. Presence of the Error Code and 825 Message are indicated by the AVP Length field. The Error Message 826 contains an arbitrary string providing further (human readable) 827 text associated with the condition. Human readable text in all 828 error messages MUST be provided in the UTF-8 charset using the 829 Default Language [RFC2277]. 831 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 832 this AVP MUST be set to 1. The Length is 8 if there is no Error 833 Code or Message, 10 if there is an Error Code and no Error Message 834 or 10 + the length of the Error Message if there is an Error Code 835 and Message. 837 Defined Result Code values for the StopCCN message are: 839 0 - Reserved 840 1 - General request to clear control connection 841 2 - General error--Error Code indicates the problem 842 3 - Control channel already exists 843 4 - Requester is not authorized to establish a control channel 844 5 - The protocol version of the requester is not supported 845 Error Code indicates highest version supported 846 6 - Requester is being shut down 847 7 - Finite State Machine error 849 Defined Result Code values for the CDN message are: 851 0 - Reserved 852 1 - Call disconnected due to loss of carrier 853 2 - Call disconnected for the reason indicated 854 in error code 855 3 - Call disconnected for administrative reasons 856 4 - Call failed due to lack of appropriate facilities being 857 available (temporary condition) 859 5 - Call failed due to lack of appropriate facilities being 860 available (permanent condition) 861 6 - Invalid destination 862 7 - Call failed due to no carrier detected 863 8 - Call failed due to detection of a busy signal 864 9 - Call failed due to lack of a dial tone 865 10 - Call was not established within time allotted by LAC 866 11 - Call was connected but no appropriate framing was detected 868 The Error Codes defined below pertain to types of errors that are 869 not specific to any particular L2TP request, but rather to 870 protocol or message format errors. If an L2TP reply indicates in 871 its Result Code that a general error occurred, the General Error 872 value should be examined to determine what the error was. The 873 currently defined General Error codes and their meanings are: 875 0 - No general error 876 1 - No control connection exists yet for this LAC-LNS pair 877 2 - Length is wrong 878 3 - One of the field values was out of range or 879 reserved field was non-zero 880 4 - Insufficient resources to handle this operation now 881 5 - The Session ID is invalid in this context 882 6 - A generic vendor-specific error occurred in the LAC 883 7 - Try another. If LAC is aware of other possible LNS 884 destinations, it should try one of them. This can be 885 used to guide an LAC based on LNS policy, for instance, 886 the existence of multilink PPP bundles. 887 8 - Session or tunnel was shutdown due to receipt of an unknown 888 AVP with the M-bit set (see section 4.2). The Error Message 889 SHOULD contain the attribute of the offending AVP in (human 890 readable) text form. 892 When a General Error Code of 6 is used, additional information 893 about the error SHOULD be included in the Error Message field. 895 4.4.3 Control Connection Management AVPs 897 Protocol Version (SCCRP, SCCRQ) 899 The Protocol Version AVP, Attribute Type 2, indicates the L2TP 900 protocol version of the sender. 902 The Attribute Value field for this AVP has the following format: 904 0 1 905 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Ver | Rev | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 The Ver field is a 1 octet unsigned integer containing the value 911 1. Rev field is a 1 octet unsigned integer containing 0. This 912 pertains to L2TP protocol version 1, revision 0. Note this is not 913 the same version number that is included in the header of each 914 message. 916 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 917 this AVP MUST be set to 1. The Length of this AVP is 8. 919 Framing Capabilities (SCCRP, SCCRQ) 921 The Framing Capabilities AVP, Attribute Type 3, provides the peer 922 with an indication of the types of framing that will be accepted 923 or requested by the sender. 925 The Attribute Value field for this AVP has the following format: 927 0 1 2 3 928 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Reserved for future framing type definitions |A|S| 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 The Attribute Value field is a 32-bit mask, with two bits defined. 934 If bit A is set, asynchronous framing is supported. If bit S is 935 set, synchronous framing is supported. 937 A peer MUST NOT request an incoming or outgoing call with a 938 Framing Type AVP specifying a value not advertised in the Framing 939 Capabilities AVP it received during control connection 940 establishment. Attempts to do so will result in the call being 941 rejected. 943 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 944 this AVP MUST be set to 1. The Length (before hiding) is 10. 946 Bearer Capabilities (SCCRP, SCCRQ) 948 The Bearer Capabilities AVP, Attribute Type 4, provides the peer 949 with an indication of the bearer device types supported by the 950 hardware interfaces of the sender for outgoing calls. 952 The Attribute Value field for this AVP has the following format: 954 0 1 2 3 955 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Reserved for future bearer type definitions |A|D| 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 This is a 32-bit mask, with two bits defined. If bit A is set, 961 analog access is supported. If bit D is set, digital access is 962 supported. 964 An LNS should not request an outgoing call specifying a value in 965 the Bearer Type AVP for a device type not advertised in the Bearer 966 Capabilities AVP it received from the LAC during control 967 connection establishment. Attempts to do so will result in the 968 call being rejected. 970 This AVP MUST be present if the sender can place outgoing calls 971 when requested. 973 Note that an LNS that cannot act as an LAC as well will not 974 support hardware devices for handling incoming and outgoing calls 975 and should therefore set the A and D bits of this AVP to 0, or 976 should not send the AVP at all. An LNS that can also act as an LAC 977 and place outgoing calls should set A or D as appropriate. 978 Presence of this message is not a guarantee that a given outgoing 979 call will be placed by the sender if requested, just that the 980 physical capability exists. 982 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 983 this AVP MUST be set to 1. The Length (before hiding) is 10. 985 Tie Breaker (SCCRQ) 987 The Tie Breaker AVP, Attribute Type 5, indicates that the sender 988 wishes a single tunnel to exist between the given LAC-LNS pair. 990 The Attribute Value field for this AVP has the following format: 992 0 1 2 3 993 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | Tie Break Value... 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 ...(64 bits) | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 The Tie Breaker Value is an 8 octet value that is used to choose a 1000 single tunnel where both LAC and LNS request a tunnel 1001 concurrently. The recipient of a SCCRQ must check to see if a 1002 SCCRQ has been sent to the peer, and if so, must compare its Tie 1003 Breaker value with the received one. The lower value "wins", and 1004 the "loser" MUST silently discard its tunnel. In the case where a 1005 tie breaker is present on both sides, and the value is equal, both 1006 sides MUST discard their tunnels. 1008 If a tie breaker is received, and an outstanding SCCRQ had no tie 1009 breaker value, the initiator which included the Tie Breaker AVP 1010 "wins". If neither side issues a tie breaker, then two separate 1011 tunnels are opened. 1013 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1014 this AVP MUST be set to 0. The Length of this AVP is 14. 1016 Firmware Revision (SCCRP, SCCRQ) 1018 The Firmware Revision AVP, Attribute Type 6, indicates the 1019 firmware revision of the issuing device. 1021 The Attribute Value field for this AVP has the following format: 1023 0 1 1024 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Firmware Revision | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 The Firmware Revision is a 2 octet unsigned integer encoded in a 1030 vendor specific format. 1032 For devices which do not have a firmware revision (general purpose 1033 computers running L2TP software modules, for instance), the 1034 revision of the L2TP software module may be reported instead. 1036 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1037 this AVP MUST be set to 0. The Length (before hiding) is 8. 1039 Host Name (SCCRP, SCCRQ) 1041 The Host Name AVP, Attribute Type 7, indicates the name of the 1042 issuing LAC or LNS. 1044 The Attribute Value field for this AVP has the following format: 1046 0 1 2 3 1047 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Host Name ... (arbitrary number of octets) 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 The Host Name is of arbitrary length, but MUST be at least 1 1053 octet. 1055 This name should be as broadly unique as possible; for hosts 1056 participating in DNS [RFC1034], a hostname with fully qualified 1057 domain would be appropriate. 1059 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1060 this AVP MUST be set to 1. The Length of this AVP is 6 plus the 1061 length of the Host Name. 1063 Vendor Name (SCCRP, SCCRQ) 1065 The Vendor Name AVP, Attribute Type 8, contains a vendor specific 1066 (possibly human readable) string describing the type of LAC or LNS 1067 being used. 1069 The Attribute Value field for this AVP has the following format: 1071 0 1 2 3 1072 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | Vendor Name ...(arbitrary number of octets) 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 The Vendor Name is the indicated number of octets representing the 1078 vendor string. Human readable text for this AVP MUST be provided 1079 in the UTF-8 charset using the Default Language [RFC2277]. 1081 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1082 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1083 is 6 plus the length of the Vendor Name. 1085 Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN) 1087 The Assigned Tunnel ID AVP, Attribute Type 9, encodes the ID being 1088 assigned to this tunnel by the sender. 1090 The Attribute Value field for this AVP has the following format: 1092 0 1 1093 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Assigned Tunnel ID | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 The Assigned Tunnel ID is a 2 octet non-zero unsigned integer. 1100 The Assigned Tunnel ID AVP establishes a value used to multiplex 1101 and demultiplex multiple tunnels between the LNS and LAC. The L2TP 1102 peer MUST place this value in the Tunnel ID header field of all 1103 control and data messages that it subsequently transmits over the 1104 associated tunnel. Before the Assigned Tunnel ID AVP is received 1105 from a peer, messages MUST be sent to that peer with a Tunnel ID 1106 value of 0 in the header of all control messages. 1108 In the StopCCN control message, the Assigned Tunnel ID AVP MUST be 1109 the same as the Assigned Tunnel ID AVP first sent to the receiving 1110 peer, permitting the peer to identify the appropriate tunnel even 1111 if a StopCCN is sent before an Assigned Tunnel ID AVP is received. 1113 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1114 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1115 is 8. 1117 Receive Window Size (SCCRQ, SCCRP) 1119 The Receive Window Size AVP, Attribute Type 10, specifies the 1120 receive window size being offered to the remote peer. 1122 The Attribute Value field for this AVP has the following format: 1124 0 1 1125 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | Window Size | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 The Window Size is a 2 octet unsigned integer. 1132 If absent, the peer must assume a Window Size of 4 for its 1133 transmit window. The remote peer may send the specified number of 1134 control messages before it must wait for an acknowledgment. 1136 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1137 this AVP MUST be set to 1. The Length of this AVP is 8. 1139 Challenge (SCCRP, SCCRQ) 1140 The Challenge AVP, Attribute Type 11, indicates that the issuing 1141 peer wishes to authenticate the tunnel endpoints using a CHAP- 1142 style authentication mechanism. 1144 The Attribute Value field for this AVP has the following format: 1146 0 1 2 3 1147 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | Challenge ... (arbitrary number of octets) 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 The Challenge is one or more octets of random data. 1154 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1155 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1156 is 6 plus the length of the Challenge. 1158 Challenge Response (SCCCN, SCCRP) 1160 The Response AVP, Attribute Type 13, provides a response to a 1161 challenge received. 1163 The Attribute Value field for this AVP has the following format: 1165 0 1 2 3 1166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | Response ... 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 ... (16 octets) | 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 The Response is a 16 octet value reflecting the CHAP-style 1178 [RFC1994] response to the challenge. 1180 This AVP MUST be present in an SCCRP or SCCCN if a challenge was 1181 received in the preceeding SCCRQ or SCCRP. For purposes of the ID 1182 value in the CHAP response calculation, the value of the Message 1183 Type AVP for this message is used (e.g. 2 for an SCCRP, and 3 for 1184 an SCCCN). 1186 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1187 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1188 is 22. 1190 4.4.4 Call Management AVPs 1192 Q.931 Cause Code (CDN) 1194 The Q.931 Cause Code AVP, Attribute Type 12, is used to give 1195 additional information in case of unsolicited call disconnection. 1197 The Attribute Value field for this AVP has the following format: 1199 0 1 2 3 1200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | Cause Code | Cause Msg | Advisory Msg... 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 Cause Code is the returned Q.931 Cause code, and Cause Msg is the 1206 returned Q.931 message code (e.g., DISCONNECT) associated with the 1207 Cause Code. Both values are returned in their native ITU 1208 encodings [DSS1]. An additional ASCII text Advisory Message may 1209 also be included (presence indicated by the AVP Length) to further 1210 explain the reason for disconnecting. 1212 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1213 this AVP MUST be set to 1. The Length of this AVP is 9, plus the 1214 size of the Advisory Message. 1216 Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ) 1218 The Assigned Session ID AVP, Attribute Type 14, encodes the ID 1219 being assigned to this session by the sender. 1221 The Attribute Value field for this AVP has the following format: 1223 0 1 1224 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | Assigned Session ID | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 The Assigned Session ID is a 2 octet non-zero unsigned integer. 1231 The Assigned Session ID AVP is establishes a value used to 1232 multiplex and demultiplex data sent over a tunnel between the LNS 1233 and LAC. The L2TP peer MUST place this value in the Session ID 1234 header field of all control and data messages that it subsequently 1235 transmits over the tunnel that belong to this session. Before the 1236 Assigned Session ID AVP is received from a peer, messages MUST be 1237 sent to that peer with a Session ID of 0 in the header of all 1238 control messages. 1240 In the CDN control message, the same Assigned Session ID AVP first 1241 sent to the receiving peer is used, permitting the peer to 1242 identify the appropriate tunnel even if CDN is sent before an 1243 Assigned Session ID is received. 1245 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1246 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1247 is 8. 1249 Call Serial Number (ICRQ, OCRQ) 1251 The Call Serial Number AVP, Attribute Type 15, encodes an 1252 identifier assigned by the LAC or LNS to this call. 1254 The Attribute Value field for this AVP has the following format: 1256 0 1 2 3 1257 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | Call Serial Number | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 The Call Serial Number is a 32 bit value. 1264 The Call Serial Number is intended to be an easy reference for 1265 administrators on both ends of a tunnel to use when investigating 1266 call failure problems. Call Serial Numbers should be set to 1267 progressively increasing values, which are likely to be unique for 1268 a significant period of time across all interconnected LNSs and 1269 LACs. 1271 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1272 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1273 is 10. 1275 Minimum BPS (OCRQ) 1277 The Minimum BPS AVP, Attribute Type 16, encodes the lowest 1278 acceptable line speed for this call. 1280 The Attribute Value field for this AVP has the following format: 1282 0 1 2 3 1283 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | Minimum BPS | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 The Minimum BPS is a 32 bit value indicates the speed in bits per 1289 second. 1291 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1292 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1293 is 10. 1295 Maximum BPS (OCRQ) 1297 The Maximum BPS AVP, Attribute Type 17, encodes the highest 1298 acceptable line speed for this call. 1300 The Attribute Value field for this AVP has the following format: 1302 0 1 2 3 1303 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | Maximum BPS | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 The Maximum BPS is a 32 bit value indicates the speed in bits per 1309 second. 1311 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1312 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1313 is 10. 1315 Bearer Type (ICRQ, OCRQ) 1317 The Bearer Type AVP, Attribute Type 18, encodes the bearer type 1318 for the incoming or outgoing call. 1320 The Attribute Value field for this AVP has the following format: 1322 0 1 2 3 1323 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | Reserved for future Bearer Types |A|D| 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 The Bearer Type is a 32-bit bit mask, which indicates the bearer 1329 capability of the call (ICRQ) or required for the call (OCRQ). If 1330 set, bit A indicates that the call refers to an analog channel. If 1331 set, bit D indicates that the call refers to a digital channel. 1332 Both may be set, indicating that the call was either 1333 indistinguishable, or can be placed on either type of channel. 1335 Bits in the Value field of this AVP MUST only be set by the LNS 1336 for an OCRQ if it was set in the Bearer Capabilities AVP received 1337 from the LAC during control connection establishment. 1339 It is valid to set neither the A nor D bits in an ICRQ. Such a 1340 setting may indicate that the call was not received over a 1341 physical link (e.g if the LAC and PPP are located in the same 1342 subsystem). 1344 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1345 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1346 is 10. 1348 Framing Type (ICCN, OCCN, OCRQ) 1350 The Framing Type AVP, Attribute Type 19, encodes the framing type 1351 for the incoming or outgoing call. 1353 The Attribute Value field for this AVP has the following format: 1355 0 1 2 3 1356 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | Reserved for future Framing Types |A|S| 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 The Framing Type is a 32-bit mask, which indicates the type of PPP 1362 framing requested for an OCRQ, or the type of PPP framing 1363 negotiated for an OCCN or ICCN. The framing type MAY be used as an 1364 indication to PPP on the LNS as to what link options to use for 1365 LCP negotiation [RFC1662]. 1367 Bit A indicates asynchronous framing. Bit S indicates synchronous 1368 framing. For an OCRQ, both may be set, indicating that either type 1369 of framing may be used. 1371 Bits in the Value field of this AVP MUST only be set by the LNS 1372 for an OCRQ if it was set in the Framing Capabilities AVP received 1373 from the LAC during control connection establishment. 1375 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1376 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1377 is 10. 1379 Called Number (ICRQ, OCRQ) 1381 The Called Number AVP, Attribute Type 21, encodes the telephone 1382 number to be called for an OCRQ, and the Called number for an 1383 ICRQ. 1385 The Attribute Value field for this AVP has the following format: 1387 0 1 2 3 1388 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Called Number... (arbitrary number of octets) | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 The Called Number is an ASCII string. Contact between the 1394 administrator of the LAC and the LNS may be necessary to 1395 coordinate interpretation of the value needed in this AVP. 1397 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1398 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1399 is 6 plus the length of the Called Number. 1401 Calling Number (ICRQ) 1403 The Calling Number AVP, Attribute Type 22, encodes the originating 1404 number for the incoming call. 1406 The Attribute Value field for this AVP has the following format: 1408 0 1 2 3 1409 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 | Calling Number... (arbitrary number of octets) | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 Calling Number is an ASCII string. Contact between the 1415 administrator of the LAC and the LNS may be necessary to 1416 coordinate interpretation of the value in this AVP. 1418 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1419 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1420 is 6 plus the length of the Calling Number. 1422 Sub-Address (ICRQ, OCRQ) 1424 The Sub-Address AVP, Attribute Type 23, encodes additional dialing 1425 information. 1427 The Attribute Value field for this AVP has the following format: 1429 0 1 2 3 1430 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | Sub-Address ... (arbitrary number of octets) | 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 The Sub-Address is an ASCII string. Contact between the 1436 administrator of the LAC and the LNS may be necessary to 1437 coordinate interpretation of the value in this AVP. 1439 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1440 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1441 is 6 plus the length of the Sub-Address. 1443 (Tx) Connect Speed (ICCN, OCCN) 1445 The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes the 1446 speed of the facility chosen for the connection attempt. 1448 The Attribute Value field for this AVP has the following format: 1450 0 1 2 3 1451 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | BPS | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 The (Tx) Connect Speed BPS is a 4 octet value indicating the speed 1457 in bits per second. 1459 When the optional Rx Connect Speed AVP is present, the value in 1460 this AVP represents the transmit connect speed, from the 1461 perspective of the LAC (e.g. data flowing from the LAC to the 1462 remote system). When the optional Rx Connect Speed AVP is NOT 1463 present, the connection speed between the remote system and LAC is 1464 assumed to be symmetric and is represented by the single value in 1465 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 10. 1471 Rx Connect Speed (ICCN, OCCN) 1473 The Rx Connect Speed AVP, Attribute Type 38, represents the speed 1474 of the connection from the perspective of the LAC (e.g. data 1475 flowing from the remote system to the LAC). 1477 The Attribute Value field for this AVP has the following format: 1479 0 1 2 3 1480 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 | BPS (H) | BPS (L) | 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 BPS is a 4 octet value indicating the speed in bits per second. 1487 Presence of this AVP implies that the connection speed may be 1488 asymmetric with respect to the transmit connect speed given in the 1489 (Tx) Connect Speed AVP. 1491 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for 1492 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1493 is 10. 1495 Physical Channel ID (ICRQ, OCRP) 1497 The Physical Channel ID AVP, Attribute Type 25, encodes the vendor 1498 specific physical channel number used for a call. 1500 The Attribute Value field for this AVP has the following format: 1502 0 1 2 3 1503 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 | Physical Channel ID | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 Physical Channel ID is a 4 octet value intended to be used for 1509 logging purposes only. 1511 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1512 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1513 is 10. 1515 Private Group ID (ICCN) 1517 The Private Group ID AVP, Attribute Type 37, is used by the LAC to 1518 indicate that this call is to be associated with a particular 1519 customer group. 1521 The Attribute Value field for this AVP has the following format: 1523 0 1 2 3 1524 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | Private Group ID ... (arbitrary number of octets) | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 The Private Group ID is a string of octets of arbitrary length. 1531 The LNS MAY treat the PPP session as well as network traffic 1532 through this session in a special manner determined by the peer. 1533 For example, if the LNS is individually connected to several 1534 private networks using unregistered addresses, this AVP may be 1535 included by the LAC to indicate that a given call should be 1536 associated with one of the private networks. 1538 The Private Group ID is a string corresponding to a table in the 1539 LNS that defines the particular characteristics of the selected 1540 group. A LAC MAY determine the Private Group ID from a RADIUS 1541 response, local configuration, or some other source. 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 6 plus the length of the Private Group ID. 1547 Sequencing Required (ICCN, OCCN) 1549 The Sequencing Required AVP, Attribute Type 39, indicates to the 1550 LNS that Sequence Numbers MUST always be present on the data 1551 channel. 1553 This AVP has no Attribute Value field. 1555 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1556 this AVP MUST be set to 1. The Length of this AVP is 6. 1558 4.4.5 Proxy LCP and Authentication AVPs 1560 The LAC may have answered the call and negotiated LCP with the 1561 remote system, perhaps in order to establish the system's apparent 1562 identity. In this case, these AVPs may be included to indicate the 1563 link properties the remote system initially requested, properties 1564 the remote system and LAC ultimately negotiated, as well as PPP 1565 authentication information sent and received by the LAC. This 1566 information may be used to initiate the PPP LCP and authentication 1567 systems on the LNS, allowing PPP to continue without renegotiation 1568 of LCP. Note that the LNS policy may be to enter an additional 1569 round of LCP negotiation and/or authentication if the LAC is not 1570 trusted. 1572 Initial Received LCP CONFREQ (ICCN) 1574 In the Initial Received LCP CONFREQ AVP, Attribute Type 26, 1575 provides the LNS with the Initial CONFREQ received by the LAC from 1576 the PPP Peer. 1578 The Attribute Value field for this AVP has the following format: 1580 0 1 2 3 1581 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 | LCP CONFREQ... (arbitrary number of octets) | 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 LCP CONFREQ is a copy of the body of the initial CONFREQ received, 1587 starting at the first option within the body of the LCP message. 1589 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1590 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1591 is 6 plus the length of the CONFREQ. 1593 Last Sent LCP CONFREQ (ICCN) 1595 In the Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the 1596 LNS with the Last CONFREQ sent by the LAC to the PPP Peer. 1598 The Attribute Value field for this AVP has the following format: 1600 0 1 2 3 1601 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | LCP CONFREQ... (arbitrary number of octets) | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 The LCP CONFREQ is a copy of the body of the final CONFREQ sent to 1607 the client to complete LCP negotiation, starting at the first 1608 option within the body of the LCP message. 1610 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1611 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1612 is 6 plus the length of the CONFREQ. 1614 Last Received LCP CONFREQ (ICCN) 1616 The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the 1617 LNS with the Last CONFREQ received by the LAC from the PPP Peer. 1619 The Attribute Value field for this AVP has the following format: 1621 0 1 2 3 1622 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | LCP CONFREQ... (arbitrary number of octets) | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 The LCP CONFREQ is a copy of the body of the final CONFREQ 1628 received from the client to complete LCP negotiation, starting at 1629 the first option within the body of the LCP message. 1631 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1632 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1633 is 6 plus the length of the CONFREQ. 1635 Proxy Authen Type (ICCN) 1637 The Proxy Authen Type AVP, Attribute Type 29, determines if proxy 1638 authentication should be used. 1640 The Attribute Value field for this AVP has the following format: 1642 0 1 1643 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | Authen Type | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 Authen Type is a 2 octet unsigned integer, holding: 1650 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1651 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1652 is 8. 1654 Defined Authen Type values are: 1655 0 - Reserved 1656 1 - Textual username/password exchange 1657 2 - PPP CHAP 1658 3 - PPP PAP 1659 4 - No Authentication 1660 5 - Microsoft CHAP Version 1 (MSCHAPv1) 1662 This AVP MUST be present if proxy authentication is to be 1663 utilized. If it is not present, then it is assumed that this 1664 peer cannot perform proxy authentication, requiring 1665 a restart of the authentication phase at the LNS if the client 1666 has already entered this phase with the 1667 LAC (which may be determined by the Proxy LCP AVP if present). 1669 Associated AVPs for each type of authentication follow. 1671 Proxy Authen Name (ICCN) 1673 The Proxy Authen Name AVP, Attribute Type 30, specifies the name 1674 of the authenticating client when using proxy authentication. 1676 The Attribute Value field for this AVP has the following format: 1678 0 1 2 3 1679 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 | Authen Name... (arbitrary number of octets) | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1684 Authen Name is a string of octets of arbitrary length. It 1685 contains the name specified in the client's authentication 1686 response. 1688 This AVP MUST be present in messages containing a Proxy Authen 1689 Type AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable 1690 to employ AVP hiding for obscuring the cleartext name. 1692 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1693 this AVP MUST be set to 0. The Length (before hiding) is 6 plus 1694 the length of the cleartext name. 1696 Proxy Authen Challenge (ICCN) 1698 The Proxy Authen Challenge AVP, Attribute Type 31, specifies the 1699 challenge sent by the LAC to the PPP Peer, when using proxy 1700 authentication. 1702 The Attribute Value field for this AVP has the following format: 1704 0 1 2 3 1705 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 | Challenge... (arbitrary number of octets) | 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 The Challenge is a string of one or more octets. 1712 This AVP MUST be present for Proxy Authen Types 2 and 5. The 1713 Challenge field contains the CHAP challenge presented to the 1714 client by the LAC. 1716 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1717 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1718 is 6, plus the length of the Challenge. 1720 Proxy Authen ID (ICCN) 1722 The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value 1723 of the PPP Authentication that was started between the LAC and the 1724 PPP Peer, when proxy authentication is being used. 1726 The Attribute Value field for this AVP has the following format: 1728 0 1 1729 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 | Reserved | ID | 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 ID is a 2 octet unsigned integer, the most significant octet MUST 1735 be 0. 1737 The Proxy Authen ID AVP MUST be present for Proxy authen types 2, 1738 3 and 5. For 2 and 5, the ID field contains the byte ID value 1739 presented to the client by the LAC in its Challenge. For 3, it is 1740 the Identifier value of the Authenticate-Request. 1742 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1743 this AVP MUST be set to 0. 1745 Proxy Authen Response (ICCN) 1747 The Proxy Authen Response AVP, Attribute Type 33, specifies the 1748 PPP Authentication response received by the LAC from the PPP Peer, 1749 when proxy authentication is used. 1751 The Attribute Value field for this AVP has the following format: 1753 0 1 2 3 1754 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 | Response... (arbitrary number of octets) | 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 The Response is a string of octets. 1761 This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The 1762 Response field contains the client's response to the challenge. 1763 For Proxy authen types 2 and 5, this field contains the response 1764 value received by the LAC. For types 1 or 3, it contains the clear 1765 text password received from the client by the LAC. In the case of 1766 cleartext passwords, AVP hiding is recommended. 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 Response. 1772 4.4.6 Call Status AVPs 1774 Call Errors (WEN) 1776 The Call Errors AVP, Attribute Type 34, is used by the LAC to send 1777 error information to the LNS. 1779 The Attribute Value field for this AVP has the following format: 1781 0 1 2 3 1782 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | Reserved | CRC Errors (H) | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | CRC Errors (L) | Framing Errors (H) | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | Framing Errors (L) | Hardware Overruns (H) | 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | Hardware Overruns (L) | Buffer Overruns (H) | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | Buffer Overruns (L) | Time-out Errors (H) | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | Time-out Errors (L) | Alignment Errors (H) | 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | Alignment Errors (L) | 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 The following fields are defined: 1801 Reserved - Not used, MUST be 0 1802 CRC Errors - Number of PPP frames received with CRC errors 1803 since call was established 1804 Framing Errors - Number of improperly framed PPP packets 1805 received 1806 Hardware Overruns - Number of receive buffer over-runs since 1807 call was established 1808 Buffer Overruns - Number of buffer over-runs detected since 1809 call was established 1810 Time-out Errors - Number of time-outs since call was 1811 established 1812 Alignment Errors - Number of alignment errors since call was 1813 established 1815 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1816 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1817 is 32. 1819 ACCM (SLI) 1821 The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC 1822 of the ACCM negotiated with the PPP Peer by the LNS. 1824 The Attribute Value field for this AVP has the following format: 1826 0 1 2 3 1827 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 | Reserved | Send ACCM (H) | 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 | Send ACCM (L) | Receive ACCM (H) | 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 | Receive ACCM (L) | 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 Send ACCM and Receive ACCM are each 4 octet values preceeded by a 1837 2 octet reserved quantity. The send ACCM value should be used by 1838 the LAC to process packets it sends on the connection. The receive 1839 ACCM value should be used by the LAC to process incoming packets 1840 on the connection. The default values used by the LAC for both 1841 these fields are 0xFFFFFFFF. The LAC should honor these fields 1842 unless it has specific configuration information to indicate that 1843 the requested mask must be modified to permit operation. 1845 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for 1846 this AVP MUST be set to 1. The Length of this AVP is 16. 1848 5.0 Protocol Operation 1850 The necessary setup for tunneling a PPP session with L2TP consists of 1851 two steps, (1) establishing the Control Connection for a Tunnel, and 1852 (2) establishing a Session as triggered by an incoming or outgoing 1853 call request. The Tunnel and corresponding Control Connection MUST be 1854 established before an incoming or outgoing call is initiated. An L2TP 1855 Session MUST be established before L2TP can begin to tunnel PPP 1856 frames. Multiple Sessions may exist across a single Tunnel and 1857 multiple Tunnels may exist between the same LAC and LNS.. 1859 +-----+ +-----+ 1860 | |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~| | 1861 | LAC | | LNS | 1862 | #######Control Connection######## | 1863 [Remote] | | | | 1864 [System]------Call----------*============L2TP Session=============* | 1865 PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | 1866 | | | | 1867 [Remote] | | | | 1868 [System]------Call----------*============L2TP Session=============* | 1869 PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | 1870 | | | | 1871 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | 1872 +-----+ +-----+ 1874 Figure 5.1 Tunneling PPP 1876 5.1 Control Connection Establishment 1878 The Control Connection is the initial connection that must be 1879 achieved between an LAC and LNS before sessions may be brought up. 1880 Establishment of the control connection includes securing the 1881 identity of the peer, as well as identifying the peer's L2TP version, 1882 framing, and bearer capabilities, etc. 1884 A three message exchange is utilized to setup the control connection. 1885 Following is a typical message exchange: 1887 LAC or LNS LAC or LNS 1888 ---------- ---------- 1889 SCCRQ -> 1890 <- SCCRP 1891 SCCCN -> 1892 <- ZLB ACK 1894 The ZLB ACK is sent if there are no further messages waiting in queue 1895 for that peer. 1897 5.1.1 Tunnel Authentication 1899 L2TP incorporates a simple, optional, CHAP-like [RFC1994] tunnel 1900 authentication system during control connection establishment. If 1901 an LAC or LNS wishes to authenticate the identity of the peer it 1902 is contacting or being contacted by, a Challenge AVP is included 1903 in the SCCRQ or SCCRP message. If a Challenge AVP is received in 1904 an SCCRQ or SCCRP, a Challenge Response AVP MUST be sent in the 1905 following SCCRP or SCCCN, respectively. If the expected response 1906 and response received from a peer does not match, establishment of 1907 the tunnel MUST be disallowed. 1909 To participate in tunnel authentication, a single shared secret 1910 MUST exist between the LAC and LNS. This is the same shared secret 1911 used for AVP hiding (see Section 4.3). See Section 4.4.3 for 1912 details on construction of the Challenge and Response AVPs. 1914 5.2 Session Establishment 1916 After successful control connection establishment, individual 1917 sessions may be created. Each session corresponds to single PPP 1918 stream between the LAC and LNS. Unlike control connection 1919 establishment, session establishment is directional with respect to 1920 the LAC and LNS. The LAC requests the LNS to accept a session for an 1921 incoming call, and the LNS requests the LAC to accept a session for 1922 placing an outgoing call. 1924 5.2.1 Incoming Call Establishment 1926 A three message exchange is employed to setup the session. 1927 Following is a typical sequence of events: 1929 LAC LNS 1930 --- --- 1931 (Call 1932 Detected) 1934 ICRQ -> 1935 <- ICRP 1936 ICCN -> 1937 <- ZLB ACK 1939 The ZLB ACK is sent if there are no further messages waiting in 1940 queue for that peer. 1942 5.2.2 Outgoing Call Establishment 1944 A three message exchange is employed to setup the session. 1945 Following is a typical sequence of events: 1947 LAC LNS 1948 --- --- 1949 <- OCRQ 1950 OCRP -> 1952 (Perform 1953 Call 1954 Operation) 1956 OCCN -> 1957 <- ZLB ACK 1959 The ZLB ACK is sent if there are no further messages waiting in 1960 queue for that peer. 1962 5.3 Forwarding PPP Frames 1964 Once tunnel establishment is complete, PPP frames from the remote 1965 system are received at the LAC, stripped of CRC, link framing, and 1966 transparency bytes, encapsulated in L2TP, and forwarded over the 1967 appropriate tunnel. The LNS receives the L2TP packet, and processes 1968 the encapsulated PPP frame as if it were received on a local PPP 1969 interface. 1971 The sender of a message associated with a particular session and 1972 tunnel places the Session ID and Tunnel ID (specified by its peer) in 1973 the Session ID and Tunnel ID header for all outgoing messages. In 1974 this manner, PPP frames are multiplexed and demultiplexed over a 1975 single tunnel between a given LNS-LAC pair. Multiple tunnels may 1976 exist between a given LNS-LAC pair, and multiple sessions may exist 1977 within a tunnel. 1979 The value of 0 for Session ID and Tunnel ID is special and MUST NOT 1980 be used as an Assigned Session ID or Assigned Tunnel ID. For the 1981 cases where a Session ID has not yet been assigned by the peer (i.e., 1982 during establishment of a new session or tunnel), the Session ID 1983 field MUST be sent as 0, and the Assigned Session ID AVP within the 1984 message MUST be used to identify the session. Similarly, for cases 1985 where the Tunnel ID has not yet been assigned from the peer, the 1986 Tunnel ID MUST be sent as 0 and Assigned Tunnel ID AVP used to 1987 identify the tunnel. 1989 5.4 Using Sequence Numbers on the Data Channel 1991 Sequence numbers are defined in the L2TP header for control messages 1992 and optionally for data messages (see Section 3.1). These are used to 1993 provide a reliable control message transport (see Section 5.8) and 1994 optional data message sequencing. Each peer maintains separate 1995 sequence numbers for the control connection and each individual data 1996 session within a tunnel. 1998 Unlike the L2TP control channel, the L2TP data channel does not use 1999 sequence numbers to retransmit lost data messages. Rather, data 2000 messages may use sequence numbers to detect lost packets and/or 2001 restore the original sequence of packets that may have been reordered 2002 during transport. The LAC may request that sequence numbers be 2003 present in data messages via the Sequencing Required AVP (see Section 2004 4.4.6). If this AVP is present during session setup, sequence numbers 2005 MUST be present at all times. If this AVP is not present, sequencing 2006 presence is under control of the LNS. The LNS controls enabling and 2007 disabling of sequence numbers by sending a data message with or 2008 without sequence numbers present at any time during the life of a 2009 session. Thus, if the LAC receives a data message without sequence 2010 numbers present, it MUST stop sending sequence numbers in future data 2011 messages. If the LAC receives a data message with sequence numbers 2012 present, it MUST begin sending sequence numbers in future outgoing 2013 data messages. If the LNS enables sequencing after disabling it 2014 earlier in the session, the sequence number state picks up where it 2015 left off before. 2017 The LNS may initiate disabling of sequencing at any time during the 2018 session (including the first data message sent). It is recommended 2019 that for connections where reordering or packet loss may occur, 2020 sequence numbers always be enabled during the initial negotiation 2021 stages of PPP and disabled only when and if the risk is considered 2022 acceptable. For example, if the PPP session being tunneled is not 2023 utilizing any stateful compression or encryption protocols and is 2024 only carrying IP (as determined by the PPP NCPs that are 2025 established), then the LNS might decide to disable sequencing as IP 2026 is tolerant to datagram loss and reordering. 2028 5.5 Keepalive (Hello) 2030 A keepalive mechanism is employed by L2TP in order to differentiate 2031 tunnel outages from extended periods of no control or data activity 2032 on a tunnel. This is accomplished by injecting Hello control messages 2033 (see Section 6.5) after a specified period of time has elapsed since 2034 the last data or control message was received on a tunnel. As for any 2035 other control message, if the Hello message is not reliably delivered 2036 then the tunnel is declared down and is reset. The transport reset 2037 mechanism along with the injection of Hello messages ensures that a 2038 connectivity failure between the LNS and the LAC will be detected at 2039 both ends of a tunnel. 2041 5.6 Session Teardown 2043 Session teardown may be initiated by either the LAC or LNS and is 2044 accomplished by sending a CDN control message. After the last session 2045 is cleared, the control connection MAY be torn down as well (and 2046 typically is). Following is an example of a typical control message 2047 exchange: 2049 LAC or LNS LAC or LNS 2051 CDN -> 2052 (Clean up) 2054 <- ZLB ACK 2055 (Clean up) 2057 5.7 Control Connection Teardown 2059 Control connection teardown may be initiated by either the LAC or LNS 2060 and is accomplished by sending a single StopCCN control message. The 2061 receiver of a StopCCN MUST send a ZLB ACK to acknowledge receipt of 2062 the message and maintain enough control connection state to properly 2063 accept StopCCN retransmissions over at least a full retransmission 2064 cycle (in case the ZLB ACK is lost). The recommended time for a full 2065 retransmission cycle is 31 seconds (see section 5.8). Following is an 2066 example of a typical control message exchange: 2068 LAC or LNS LAC or LNS 2070 StopCCN -> 2071 (Clean up) 2073 <- ZLB ACK 2074 (Wait) 2075 (Clean up) 2077 An implementation may shut down an entire tunnel and all sessions on 2078 the tunnel by sending the StopCCN. Thus, it is not necessary to clear 2079 each session individually when tearing down the whole tunnel. 2081 5.8 Reliable Delivery of Control Messages 2083 L2TP provides a lower level reliable transport service for all 2084 control messages. The Nr and Ns fields of the control message header 2085 (see section 3.1) belong to this transport. The upper level 2086 functions of L2TP are not concerned with retransmission or ordering 2087 of control messages. The reliable control message is a sliding window 2088 transport that provides control message retransmission and congestion 2089 control. Each peer maintains separate sequence number state for the 2090 control connection within a tunnel. 2092 The message sequence number, Ns, begins at 0. Each subsequent message 2093 is sent with the next increment of the sequence number. The sequence 2094 number is thus a free running counter represented modulo 65536. The 2095 sequence number in the header of a received message is considered 2096 less than or equal to the last received number if its value lies in 2097 the range of the last received number and the preceding 32767 values, 2098 inclusive. For example, if the last received sequence number was 15, 2099 then messages with sequence numbers 0 through 15, as well as 32784 2100 through 65535, would be considered less than or equal. Such a message 2101 would be considered a duplicate of a message already received and 2102 ignored from processing. However, in order to ensure that all 2103 messages are ackowledged properly (particularly in the case of a lost 2104 ZLB ACK message), receipt of duplicate messages MUST be acknowledged 2105 by the reliable transport. This acknowledgement may either 2106 piggybacked on a message in queue, or explicitly via a ZLB ACK. 2108 All control messages take up one slot in the control message sequence 2109 number space, except the ZLB acknowledgement. Thus, Ns is not 2110 incremented after a ZLB message is sent. 2112 The last received message number, Nr, is used to acknowledge messages 2113 received by an L2TP peer. It contains the sequence number of the 2114 message the peer expects to receive next (e.g. the last Ns of a non- 2115 ZLB message received plus 1, modulo 65536). While the Nr in a 2116 received ZLB is used to flush messages from the local retransmit 2117 queue (see below), Nr of the next message sent is not be updated by 2118 the Ns of the ZLB. 2120 The reliable transport at a receiving peer is responsible for making 2121 sure that control messages are delivered in order and without 2122 duplication to the upper level. Messages arriving out of order may be 2123 queued for in-order delivery when the missing messages are received, 2124 or they may be discarded requiring a retransmission by the peer. 2126 Each tunnel maintains a queue of control messages to be transmitted 2127 to its peer. The message at the front of the queue is sent with a 2128 given Ns value, and is held until a control message arrives from the 2129 peer in which the Nr field indicates receipt of this message. After a 2130 period of time (a recommended default is 1 second) passes without 2131 acknowledgement, the message is retransmitted. The retransmitted 2132 message contains the same Ns value, but the Nr value MUST be updated 2133 with the sequence number of the next expected message. 2135 Each subsequent retransmission of a message MUST employ an 2136 exponential backoff interval. Thus, if the first retransmission 2137 occurred after 1 second, the next retransmission should occur after 2 2138 seconds has elapsed, then 4 seconds, etc. An implementation MAY place 2139 a cap upon the maximum interval between retransmissions. This cap 2140 MUST be no less than 8 seconds per retransmission. If no peer 2141 response is detected after several retransmissions, (a recommended 2142 default is 5, but SHOULD be configurable), the tunnel and all 2143 sessions within MUST be cleared. 2145 When a tunnel is being shut down for reasons other than loss of 2146 connectivity, the state and reliable delivery mechanisms MUST be 2147 maintained and operated for the full retransmission interval after 2148 the final message exchange has occurred. 2150 A sliding window mechanism is used for control message transmission. 2151 Consider two peers A & B. Suppose A specifies a Receive Window Size 2152 AVP with a value of N in the SCCRQ or SCCRP messages. B is now 2153 allowed to have up to N outstanding control messages. Once N have 2154 been sent, it must wait for an acknowledgment that advances the 2155 window before sending new control messages. An implementation may 2156 support a receive window of only 1 (i.e., by sending out a Receive 2157 Window Size AVP with a value of 1), but MUST accept a window of up to 2158 4 from its peer (e.g. have the ability to send 4 messages before 2159 backing off). A value of 0 for the Receive Window Size AVP is 2160 invalid. 2162 When retransmitting control messages, a slow start and congestion 2163 avoidance window adjustment procedure SHOULD be utilized. The 2164 recommended procedure for this is described in Appendix A. 2166 A peer MUST NOT withhold acknowledgment of messages as a technique 2167 for flow controlling control messages. An L2TP implementation is 2168 expected to be able to keep up with incoming control messages, 2169 possibly responding to some with errors reflecting an inability to 2170 honor the requested action. 2172 Appendix B contains examples of control message transmission, 2173 acknowledgement, and retransmission. 2175 6.0 Control Connection Protocol Specification 2177 The following control connection messages are used to establish, 2178 clear and maintain L2TP tunnels. All data is sent in network order 2179 (high order octets first). Any "reserved" or "empty" fields MUST be 2180 sent as 0 values to allow for protocol extensibility. 2182 6.1 Start-Control-Connection-Request (SCCRQ) 2184 Start-Control-Connection-Request (SCCRQ) is a control message used to 2185 initialize a tunnel between an LNS and an LAC. It is sent by either 2186 the LAC or the LNS to being the tunnel establishement process. 2188 The following AVPs MUST be present in the SCCRQ: 2190 Message Type AVP 2191 Protocol Version 2192 Host Name 2193 Framing Capabilities 2194 Assigned Tunnel ID 2196 The Following AVPs MAY be present in the SCCRQ: 2198 Bearer Capabilities 2199 Receive Window Size 2200 Challenge 2201 Tie Breaker 2202 Firmware Revision 2203 Vendor Name 2205 6.2 Start-Control-Connection-Reply (SCCRP) 2207 Start-Control-Connection-Reply (SCCRP) is a control message sent in 2208 reply to a received SCCRQ message. SCCRP is used to indicate that the 2209 SCCRQ was accepted and establishment of the tunnel should continue. 2211 The following AVPs MUST be present in the SCCRP: 2213 Message Type 2214 Protocol Version 2215 Framing Capabilities 2216 Host Name 2217 Assigned Tunnel ID 2219 The following AVPs MAY be present in the SCCRP: 2221 Bearer Capabilities 2222 Firmware Revision 2223 Vendor Name 2224 Receive Window Size 2225 Challenge 2226 Challenge Response 2228 6.3 Start-Control-Connection-Connected (SCCCN) 2230 Start-Control-Connection-Connected (SCCCN) is a control message sent 2231 in reply to an SCCRP. SCCCN completes the tunnel establishment 2232 process. 2234 The following AVP MUST be present in the SCCCN: 2236 Message Type 2238 The following AVP MAY be present in the SCCCN: 2240 Challenge Response 2242 6.4 Stop-Control-Connection-Notification (StopCCN) 2244 Stop-Control-Connection-Notification (StopCCN) is a control message 2245 sent by either the LAC or LNS to inform its peer that the tunnel is 2246 being shutdown and the control connection should be closed. In 2247 addition, all active sessions are implicitly cleared (without sending 2248 any explicit call control messages). The reason for issuing this 2249 request is indicated in the Result Code AVP. There is no explicit 2250 reply to the message, only the implicit ACK that is received by the 2251 reliable control message transport layer. 2253 The following AVPs MUST be present in the StopCCN: 2255 Message Type 2256 Assigned Tunnel ID 2257 Result Code 2259 6.5 Hello (HELLO) 2261 The Hello (HELLO) message is an L2TP control message sent by either 2262 peer of a LAC-LNS control connection. This control message is used as 2263 a "keepalive" for the tunnel. 2265 The sending of HELLO messages and the policy for sending them are 2266 left up to the implementation. A peer MUST NOT expect HELLO messages 2267 at any time or interval. As with all messages sent on the control 2268 connection, the receiver will return either a ZLB ACK or an 2269 (unrelated) message piggybacking the necessary acknowledgement 2270 information. 2272 Since a HELLO is a control message, and control messages are reliably 2273 sent by the lower level transport, this keepalive function operates 2274 by causing the transport level to reliably deliver a message. If a 2275 media interruption has occurred, the reliable transport will be 2276 unable to deliver the HELLO across, and will clean up the tunnel. 2278 Keepalives for the tunnel MAY be implemented by sending a HELLO if a 2279 period of time (a recommended default is 60 seconds, but SHOULD be 2280 configurable) has passed without receiving any message (data or 2281 control) from the peer. 2283 HELLO messages are global to the tunnel. The Session ID in a HELLO 2284 message MUST be 0. 2286 The Following AVP MUST be present in the HELLO message: 2288 Message Type 2290 6.6 Incoming-Call-Request (ICRQ) 2292 Incoming-Call-Request (ICRQ) is a control message sent by the LAC to 2293 the LNS when an incoming call is detected. It is the first in a three 2294 message exchange used for establishing a session within an L2TP 2295 tunnel. 2297 ICRQ is used to indicate that a session is to be established between 2298 the LAC and LNS for this call and provides the LNS with parameter 2299 information for the session. The LAC may defer answering the call 2300 until it has received an ICRP from the LNS indicating that the 2301 session should be established. This mechanism allows the LNS to 2302 obtain sufficient information about the call before determining 2303 whether it should be answered or not. Alternatively, the LAC may 2304 answer the call, negotiate LCP and PPP authentication, and use the 2305 information gained to choose the LNS. In this case, the call has 2306 already been answered by the time the ICRP message is received; the 2307 LAC simply spoofs the "call indication" and "call answer" steps in 2308 this case. 2310 The following AVPs MUST be present in the ICRQ: 2312 Message Type 2313 Assigned Session ID 2314 Call Serial Number 2316 The following AVPs MAY be present in the ICRQ: 2318 Bearer Type 2319 Physical Channel ID 2320 Calling Number 2321 Called Number 2322 Sub-Address 2324 6.7 Incoming-Call-Reply (ICRP) 2326 Incoming-Call-Reply (ICRP) is a control message sent by the LNS to 2327 the LAC in response to a received ICRQ message. It is the second in 2328 the three message exchange used for establishing sessions within an 2329 L2TP tunnel. 2331 ICRP is used to indicate that the ICRQ was successful and for the LAC 2332 to answer the call if it has not already done so. It also allows the 2333 LNS to indicate necessary parameters for the L2TP session. 2335 The following AVPs MUST be present in the ICRP: 2337 Message Type 2338 Assigned Session ID 2340 6.8 Incoming-Call-Connected (ICCN) 2342 Incoming-Call-Connected (ICCN) is a control message sent by the LAC 2343 to the LNS in response to a received ICRP message. It is the third 2344 message in the three message exchange used for establishing sessions 2345 within an L2TP tunnel. 2347 ICCN is used to indicate that the ICRP was accepted, the call has 2348 been answered, and that the L2TP session should move to the 2349 established state. It also provides additional information to the 2350 LNS about parameters used for the answered call (parameters that may 2351 not always available at the time the ICRQ is issued). 2353 The following AVPs MUST be present in the ICCN: 2355 Message Type 2356 (Tx) Connect Speed 2357 Framing Type 2359 The following AVPs MAY be present in the ICCN: 2361 Initial Received LCP CONFREQ 2362 Last Sent LCP CONFREQ 2363 Last Received LCP CONFREQ 2364 Proxy Authen Type 2365 Proxy Authen Name 2366 Proxy Authen Challenge 2367 Proxy Authen ID 2368 Proxy Authen Response 2369 Private Group ID 2370 Rx Connect Speed 2371 Sequencing Required 2373 6.9 Outgoing-Call-Request (OCRQ) 2375 Outgoing-Call-Request (OCRQ) is a control message sent by the LNS to 2376 the LAC to indicate that an outbound call from the LAC is to be 2377 established. It is the first in a three message exchange used for 2378 establishing a session within an L2TP tunnel. 2380 OCRQ is used to indicate that a session is to be established between 2381 the LNS and LAC for this call and provides the LAC with parameter 2382 information for both the L2TP session, and the call that is to be 2383 placed 2385 An LNS MUST have received a Bearer Capabilities AVP during tunnel 2386 establishment from an LAC in order to request an outgoing call to 2387 that LAC. 2389 The following AVPs MUST be present in the OCRQ: 2391 Message Type 2392 Assigned Session ID 2393 Call Serial Number 2394 Minimum BPS 2395 Maximum BPS 2396 Bearer Type 2397 Framing Type 2398 Called Number 2400 The following AVPs MAY be present in the OCRQ: 2402 Sub-Address 2404 6.10 Outgoing-Call-Reply (OCRP) 2406 Outgoing-Call-Reply (OCRP) is a control message sent by the LAC to 2407 the LNS in response to a received OCRQ message. It is the second in a 2408 three message exchange used for establishing a session within an L2TP 2409 tunnel. 2411 OCRP is used to indicate that the LAC is able to attempt the outbound 2412 call and returns certain parameters regarding the call attempt. 2414 The following AVPs MUST be present in the OCRP: 2416 Message Type 2417 Assigned Session ID 2419 The following AVPs MAY be present in the OCRP: 2421 Physical Channel ID 2423 6.11 Outgoing-Call-Connected (OCCN) 2425 Outgoing-Call-Connected (OCCN) is a control message sent by the LAC 2426 to the LNS following the OCRP and after the outgoing call has been 2427 completed. It is the final message in a three message exchange used 2428 for establishing a session within an L2TP tunnel. 2430 OCCN is used to indicate that the result of a requested outgoing call 2431 was successful. It also provides information to the LNS about the 2432 particular parameters obtained after the call was established. 2434 The following AVPs MUST be present in the OCCN: 2436 Message Type 2437 (Tx) Connect Speed 2438 Framing Type 2440 The following AVPs MAY be present in the OCCN: 2442 Rx Connect Speed 2443 Sequencing Required 2445 6.12 Call-Disconnect-Notify (CDN) 2447 The Call-Disconnect-Notify (CDN) message is an L2TP control message 2448 sent by either the LAC or LNS to request disconnection of a specific 2449 call within the tunnel. Its purpose is to inform the peer of the 2450 disconnection and the reason why the disconnection occurred. The peer 2451 MUST clean up any resources, and does not send back any indication of 2452 success or failure for such cleanup. 2454 The following AVPs MUST be present in the CDN: 2456 Message Type 2457 Result Code 2458 Assigned Session ID 2460 The following AVPs MAY be present in the CDN: 2462 Q.931 Cause Code 2464 6.13 WAN-Error-Notify (WEN) 2466 The WAN-Error-Notify message is an L2TP control message sent by the 2467 LAC to the LNS to indicate WAN error conditions (conditions that 2468 occur on the interface supporting PPP). The counters in this message 2469 are cumulative. This message should only be sent when an error 2470 occurs, and not more than once every 60 seconds. The counters are 2471 reset when a new call is established. 2473 The following AVPs MUST be present in the WEN: 2475 Message Type 2476 Call Errors 2478 6.14 Set-Link-Info (SLI) 2480 The Set-Link-Info message is an L2TP control message sent by the LNS 2481 to the LAC to set PPP-negotiated options. These options can change 2482 at any time during the life of the call, thus the LAC MUST be able to 2483 update its internal call information and behavior on an active PPP 2484 session. 2486 The following AVPs MUST be present in the SLI: 2488 Message Type 2489 ACCM 2491 7.0 Control Connection State Machines 2493 The control messages defined in section 6 are exchanged by way of 2494 state tables defined in this section. Tables are defined for incoming 2495 call placement, outgoing call placement, as well as for initiation of 2496 the tunnel itself. The state tables do not encode timeout and 2497 retransmission behavior, as this is handled in the underlying 2498 semantics defined in Section 5.8. 2500 7.1 Control Connection Protocol Operation 2502 This section describes the operation of various L2TP control 2503 connection functions and the Control Connection messages which are 2504 used to support them. 2506 Receipt of an invalid or unrecoverably malformed control message 2507 should be logged appropriately and the control connection cleared to 2508 ensure recovery to a known state. The control connection may then be 2509 restarted by the initator. 2511 An invalid control message is defined as a message which contains a 2512 Message Type that is marked mandatory (see Section 4.4.1) and is 2513 unknown to the implementation, or a control message that is received 2514 in an improper sequence (e.g. an SCCCN sent in reply to an SCCRQ). 2516 Examples of a malformed control message include one that has an 2517 invalid value in its header, contains an AVP that is formatted 2518 incorrectly or whose value is out of range, or a message that is 2519 missing a required AVP. A control message with a malformed header 2520 should be discarded. A control message with an invalid AVP should 2521 look to the M-bit for that AVP to determine whether the error is 2522 recoverable or not. 2524 A malformed yet recoverable non-mandatory (M-bit is not set) AVP 2525 within a control message should be treated in a similar manner as an 2526 unrecognized non-mandatory AVP. Thus, if a malformed AVP is recevied 2527 with the M-bit set, the session or tunnel should be terminated with a 2528 proper Result or Error Code sent. If the M-bit is not set, the AVP 2529 should be ignored (with the exception of logging a local error 2530 message) and the message accepted. 2532 This MUST NOT be considered a license to send malformed AVPs, but 2533 simply a guide towards how to handle an improperly formatted message 2534 if one is received. It is impossible to list all potential 2535 malformations of a given message and give advice for each. That said, 2536 one example of a recoverable, malformed AVP might be if the Rx 2537 Connect Speed AVP, attribute 38, is received with a length of 8 2538 rather than 10 and the BPS given in 2 octets rather than 4. Since the 2539 Rx Connect Speed is non-mandatory, this condition should not be 2540 considered catastrophic. As such, the control message should be 2541 accepted as if the AVP had not been received (with the exception of a 2542 local error message being logged). 2544 In several cases in the following tables, a protocol message is sent, 2545 and then a "clean up" occurs. Note that regardless of the initiator 2546 of the tunnel destruction, the reliable delivery mechanism must be 2547 allowed to run (see Section 5.8) before destroying the tunnel. This 2548 permits the tunnel management messages to be reliably delivered to 2549 the peer. 2551 Appendix B.1 contains an example of lock-step tunnel establishment. 2553 7.2 Control Connection States 2555 The L2TP control connection protocol is not distinguishable between 2556 the LNS and LAC, but is distinguishable between the originator and 2557 receiver. The originating peer is the one which first initiates 2558 establishment of the tunnel (in a tie breaker situation, this is the 2559 winner of the tie). Since either LAC or LNS can be the originator, a 2560 collision can occur. See the Tie Breaker AVP in Section 4.4.3 for a 2561 description of this and its resolution. 2563 7.2.1 Control Connection Establishment 2564 State Event Action New State 2565 ----- ----- ------ --------- 2566 idle Local Send SCCRQ wait-ctl-reply 2567 Open request 2569 idle Receive SCCRQ, Send SCCRP wait-ctl-conn 2570 acceptable 2572 idle Receive SCCRQ, Send StopCCN, idle 2573 not acceptable Clean up 2575 idle Receive SCCRP Send StopCCN idle 2576 Clean up 2578 idle Receive SCCCN Clean up idle 2580 wait-ctl-reply Receive SCCRP, Send SCCCN, established 2581 acceptable Send tunnel-open 2582 event to waiting 2583 sessions 2585 wait-ctl-reply Receive SCCRP, Send StopCCN, idle 2586 not acceptable Clean up 2588 wait-ctl-reply Receive SCCRQ, Clean up, idle 2589 lose tie-breaker Re-queue SCCRQ 2590 for idle state 2592 wait-ctl-reply Receive SCCCN Send StopCCN idle 2593 Clean up 2595 wait-ctl-conn Receive SCCCN, Send tunnel-open established 2596 acceptable event to waiting 2597 sessions 2599 wait-ctl-conn Receive SCCCN, Send StopCCN, idle 2600 not acceptable Clean up 2602 wait-ctl-conn Receive SCCRP, Send StopCCN, idle 2603 SCCRQ Clean up 2605 established Local Send tunnel-open established 2606 Open request event to waiting 2607 (new call) sessions 2609 established Admin Send StopCCN idle 2610 Tunnel Close Clean up 2612 established Receive SCCRQ, Send StopCCN idle 2613 SCCRP, SCCCN Clean up 2615 idle Receive StopCCN Clean up idle 2616 wait-ctl-reply, 2617 wait-ctl-conn, 2618 established 2620 The states associated with the LNS or LAC for control connection 2621 establishment are: 2623 idle 2624 Both initiator and recipient start from this state. An initiator 2625 transmits an SCCRQ, while a recipient remains in the idle state 2626 until receiving an SCCRQ. 2628 wait-ctl-reply 2629 The originator checks to see if another connection has been 2630 requested from the same peer, and if so, handles the collision 2631 situation described in Section 5.8. 2633 When an SCCRP is received, it is examined for a compatible 2634 version. If the version of the reply is lower than the version 2635 sent in the request, the older (lower) version should be used 2636 provided it is supported. If the version in the reply is earlier 2637 and supported, the originator moves to the established state. If 2638 the version is earlier and not supported, a StopCCN MUST be sent 2639 to the peer and the originator cleans up and terminates the 2640 tunnel. 2642 wait-ctl-conn 2643 This is where an SCCCN is awaited; upon receipt, the challenge 2644 response is checked. The tunnel either is established, or is torn 2645 down if an authorization failure is detected. 2647 established 2648 An established connection may be terminated by either a local 2649 condition or the receipt of a Stop-Control-Connection- 2650 Notification. In the event of a local termination, the originator 2651 MUST send a Stop-Control-Connection-Notification and clean up the 2652 tunnel. 2654 If the originator receives a Stop-Control-Connection-Notification 2655 it MUST also clean up the tunnel. 2657 7.3 Timing considerations 2658 Due to the real-time nature of telephone signaling, both the LNS and 2659 LAC should be implemented with multi-threaded architectures such that 2660 messages related to multiple calls are not serialized and blocked. 2661 The call and connection state figures do not specify exceptions 2662 caused by timers. These are addressed in Section 5.8. 2664 7.4 Incoming calls 2666 An Incoming-Call-Request message is generated by the LAC when an 2667 incoming call is detected (for example, an associated telephone line 2668 rings). The LAC selects a Session ID and serial number and indicates 2669 the call bearer type. Modems should always indicate analog call type. 2670 ISDN calls should indicate digital when unrestricted digital service 2671 or rate adaption is used and analog if digital modems are involved. 2672 Calling Number, Called Number, and Subaddress may be included in the 2673 message if they are available from the telephone network. 2675 Once the LAC sends the Incoming-Call-Request, it waits for a response 2676 from the LNS but it does not necessarily answer the call from the 2677 telephone network yet. The LNS may choose not to accept the call if: 2679 - No resources are available to handle more sessions 2680 - The dialed, dialing, or subaddress fields do not correspond to 2681 an authorized user 2682 - The bearer service is not authorized or supported 2684 If the LNS chooses to accept the call, it responds with an Incoming- 2685 Call-Reply. When the LAC receives the Incoming-Call-Reply, it 2686 attempts to connect the call. A final call connected message from 2687 the LAC to the LNS indicates that the call states for both the LAC 2688 and the LNS should enter the established state. If the call 2689 terminated before the LNS could accept it, a Call-Disconnect-Notify 2690 is sent by the LAC to indicate this condition. 2692 When the dialed-in client hangs up, the call is cleared normally and 2693 the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to 2694 clear a call, it sends a Call-Disconnect-Notify message and cleans up 2695 its session. 2697 7.4.1 LAC Incoming Call States 2699 State Event Action New State 2700 ----- ----- ------ --------- 2701 idle Bearer Ring or Initiate local wait-tunnel 2702 Ready to indicate tunnel open 2703 incoming conn. 2705 idle Receive ICCN, Clean up idle 2706 ICRP, CDN 2708 wait-tunnel Bearer line drop Clean up idle 2709 or local close 2710 request 2712 wait-reply Local Clean up idle 2713 close request or 2714 Bearer line drop 2716 wait-tunnel tunnel-open Send ICRQ wait-reply 2718 wait-reply Receive ICRP, Send ICCN established 2719 acceptable 2721 wait-reply Receive ICRP, Send CDN, idle 2722 Not acceptable Clean up 2724 wait-reply Receive ICRQ Send CDN idle 2725 Clean up 2727 wait-reply Receive CDN Clean up idle 2728 ICCN 2730 wait-reply Local Send CDN, idle 2731 close request or Clean up 2732 Bearer line drop 2734 established Receive CDN Clean up idle 2736 established Receive ICRQ, Send CDN, idle 2737 ICRP, ICCN Clean up 2739 established Bearer line Send CDN, idle 2740 drop or local Clean up 2741 close request 2743 The states associated with the LAC for incoming calls are: 2745 idle 2746 The LAC detects an incoming call on one of its interfaces. 2747 Typically this means an analog line is ringing or an ISDN TE has 2748 detected an incoming Q.931 SETUP message. The LAC initiates its 2749 tunnel establishment state machine, and moves to a state waiting 2750 for confirmation of the existence of a tunnel. 2752 wait-tunnel 2753 In this state the session is waiting for either the control 2754 connection to be opened or for verification that the tunnel is 2755 already open. Once an indication that the tunnel has/was opened, 2756 session control messages may be exchanged. The first of these is 2757 the Incoming-Call-Request. 2759 wait-reply 2760 The LAC receives either a CDN message indicating the LNS is not 2761 willing to accept the call (general error or don't accept) and 2762 moves back into the idle state, or an Incoming-Call-Reply message 2763 indicating the call is accepted, the LAC sends an Incoming-Call- 2764 Connected message and enters the established state. 2766 established 2767 Data is exchanged over the tunnel. The call may be cleared 2768 following: 2769 + An event on the connected interface: The LAC sends a Call- 2770 Disconnect-Notify message 2771 + Receipt of a Call-disconnect-Notify message: The LAC cleans 2772 up, disconnecting the call. 2773 + A local reason: The LAC sends a Call-Disconnect-Notify 2774 message. 2776 7.4.2 LNS Incoming Call States 2778 State Event Action New State 2779 ----- ----- ------ --------- 2780 idle Receive ICRQ, Send ICRP wait-connect 2781 acceptable 2783 idle Receive ICRQ, Send CDN, idle 2784 not acceptable Clean up 2786 idle Receive ICRP Send CDN idle 2787 Clean up 2789 idle Receive ICCN Clean up idle 2791 wait-connect Receive ICCN Prepare for established 2792 acceptable data 2794 wait-connect Receive ICCN Send CDN, idle 2795 not acceptable Clean up 2797 wait-connect Receive ICRQ, Send CDN idle 2798 ICRP Clean up 2800 idle, Receive CDN Clean up idle 2801 wait-connect, 2802 established 2804 wait-connect Local Send CDN, idle 2805 established Close request Clean up 2807 established Receive ICRQ, Send CDN idle 2808 ICRP, ICCN Clean up 2810 The states associated with the LNS for incoming calls are: 2812 idle 2813 An Incoming-Call-Request message is received. If the request is 2814 not acceptable, a Call-Disconnect-Notify is sent back to the LAC 2815 and the LNS remains in the idle state. If the Incoming-Call- 2816 Request message is acceptable, an Incoming-Call-Reply is sent. The 2817 session moves to the wait-connect state. 2819 wait-connect 2820 If the session is still connected on the LAC, the LAC sends an 2821 Incoming-Call-Connected message to the LNS which then moves into 2822 established state. The LAC may send a Call-Disconnect-Notify to 2823 indicate that the incoming caller could not be connected. This 2824 could happen, for example, if a telephone user accidentally places 2825 a standard voice call to an LAC resulting in a handshake failure 2826 on the called modem. 2828 established 2829 The session is terminated either by receipt of a Call-Disconnect- 2830 Notify message from the LAC or by sending a Call-Disconnect- 2831 Notify. Clean up follows on both sides regardless of the 2832 initiator. 2834 7.5 Outgoing calls 2836 Outgoing calls are initiated by an LNS and instruct an LAC to place a 2837 call. There are three messages for outgoing calls: Outgoing-Call- 2838 Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS 2839 sends an Outgoing-Call-Request specifying the dialed party phone 2840 number, subaddress and other parameters. The LAC MUST respond to the 2841 Outgoing-Call-Request message with an Outgoing-Call-Reply message 2842 once the LAC determines that the proper facilities exist to place the 2843 call and the call is administratively authorized. For example, is 2844 this LNS allowed to dial an international call? Once the outbound 2845 call is connected, the LAC sends an Outgoing-Call-Connected message 2846 to the LNS indicating the final result of the call attempt: 2848 7.5.1 LAC Outgoing Call States 2850 State Event Action New State 2851 ----- ----- ------ --------- 2852 idle Receive OCRQ, Send OCRP, wait-cs-answer 2853 acceptable Open bearer 2855 idle Receive OCRQ, Send CDN, idle 2856 not acceptable Clean up 2858 idle Receive OCRP Send CDN idle 2859 Clean up 2861 idle Receive OCCN, Clean up idle 2862 CDN 2864 wait-cs-answer Bearer answer, Send OCCN established 2865 framing detected 2867 wait-cs-answer Bearer failure Send CDN, idle 2868 Clean up 2870 wait-cs-answer Receive OCRQ, Send CDN idle 2871 OCRP, OCCN Clean up 2873 established Receive OCRQ, Send CDN idle 2874 OCRP, OCCN Clean up 2876 wait-cs-answer, Receive CDN Clean up idle 2877 established 2879 established Bearer line drop, Send CDN, idle 2880 Local close Clean up 2881 request 2883 The states associated with the LAC for outgoing calls are: 2885 idle 2886 If Outgoing-Call-Request is received in error, respond with a 2887 Call-Disconnect-Notify. Otherwise, allocate a physical channel and 2888 send an Outgoing-Call-Reply. Place the outbound call and move to 2889 the wait-cs-answer state. 2891 wait-cs-answer 2892 If the call is not completed or a timer expires waiting for the 2893 call to complete, send a Call-Disconnect-Notify with the 2894 appropriate error condition set and go to idle state. If a circuit 2895 switched connection is established and framing is detected, send 2896 an Outgoing-Call-Connected indicating success and go to 2897 established state. 2899 established 2900 If a Call-Disconnect-Notify is received by the LAC, the telco call 2901 MUST be released via appropriate mechanisms and the session 2902 cleaned up. If the call is disconnected by the client or the 2903 called interface, a Call-Disconnect-Notify message MUST be sent to 2904 the LNS. The sender of the Call-Disconnect-Notify message returns 2905 to the idle state after sending of the message is complete. 2907 7.5.2 LNS Outgoing Call States 2909 State Event Action New State 2910 ----- ----- ------ --------- 2911 idle Local Initiate local wait-tunnel 2912 open request tunnel-open 2914 idle Receive OCCN, Clean up idle 2915 OCRP, CDN 2917 wait-tunnel tunnel-open Send OCRQ wait-reply 2919 wait-reply Receive OCRP, none wait-connect 2920 acceptable 2922 wait-reply Receive OCRP, Send CDN idle 2923 not acceptable Clean up 2925 wait-reply Receive OCCN, Send CDN idle 2926 OCRQ Clean up 2928 wait-connect Receive OCCN none established 2930 wait-connect Receive OCRQ, Send CDN idle 2931 OCRP Clean up 2933 idle, Receive CDN, Clean up idle 2934 wait-reply, 2935 wait-connect, 2936 established 2938 established Receive OCRQ, Send CDN idle 2939 OCRP, OCCN Clean up 2941 wait-reply, Local Send CDN idle 2942 wait-connect, Close request Clean up 2943 established 2945 wait-tunnel Local Clean up idle 2946 Close request 2948 The states associated with the LNS for outgoing calls are: 2950 idle, wait-tunnel 2951 When an outgoing call is initiated, a tunnel is first created, 2952 much as the idle and wait-tunnel states for an LAC incoming call. 2953 Once a tunnel is established, an Outgoing-Call-Request message is 2954 sent to the LAC and the session moves into the wait-reply state. 2956 wait-reply 2957 If a Call-Disconnect-Notify is received, an error occurred, and 2958 the session is cleaned up and returns to idle. If an Outgoing- 2959 Call-Reply is received, the call is in progress and the session 2960 moves to the wait-connect state. 2962 wait-connect 2963 If a Call-Disconnect-Notify is received, the call failed; the 2964 session is cleaned up and returns to idle. If an Outgoing-Call- 2965 Connected is received, the call has succeeded and the session may 2966 now exchange data. 2968 established 2969 If a Call-Disconnect-Notify is received, the call has been 2970 terminated for the reason indicated in the Result and Cause Codes; 2971 the session moves back to the idle state. If the LNS chooses to 2972 terminate the session, it sends a Call-Disconnect-Notify to the 2973 LAC and then cleans up and idles its session. 2975 7.6 Tunnel Disconnection 2977 The disconnection of a tunnel consists of either peer issuing a 2978 Stop-Control-Connection-Notification. The sender of this Notification 2979 should wait a finite period of time for the acknowledgment of this 2980 message before releasing the control information associated with the 2981 tunnel. The recipient of this Notification should send an 2982 acknowledgment of the Notification and then release the associated 2983 control information. 2985 When to release a tunnel is an implementation issue and is not 2986 specified in this document. A particular implementation may use 2987 whatever policy is appropriate for determining when to release a 2988 control connection. Some implementations may leave a tunnel open for 2989 a period of time or perhaps indefinitely after the last session for 2990 that tunnel is cleared. Others may choose to disconnect the tunnel 2991 immediately after the last user connection on the tunnel disconnects. 2993 8.0 L2TP Over Specific Media 2995 L2TP is self-describing, operating at a level above the media over 2996 which it is carried. However, some details of its connection to media 2997 are required to permit interoperable implementations. The following 2998 sections describe details needed to permit interoperability over 2999 specific media. 3001 8.1 L2TP over UDP/IP 3003 L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP 3004 packet, including payload and L2TP header, is sent within a UDP 3005 datagram. The initiator of an L2TP tunnel picks an available source 3006 UDP port (which may or may not be 1701), and sends to the desired 3007 destination address at port 1701. The recipient picks a free port on 3008 its own system (which may or may not be 1701), and sends its reply to 3009 the initiator's UDP port and address, setting its own source port to 3010 the free port it found. Once the source and destination ports and 3011 addresses are established, they MUST remain static for the life of 3012 the tunnel. 3014 It has been suggested that having the recipient choose an arbitrary 3015 source port (as opposed to using the destination port in the packet 3016 initiating the tunnel, i.e., 1701) may make it more difficult for 3017 L2TP to traverse some NAT devices. Implementors should consider the 3018 potential implication of this before before choosing an arbitrary 3019 source port. 3021 IP fragmentation may occur as the L2TP packet travels over the IP 3022 substrate. L2TP makes no special efforts to optimize this. A LAC 3023 implementation MAY cause its LCP to negotiate for a specific MRU, 3024 which could optimize for LAC environments in which the MTU's of the 3025 path over which the L2TP packets are likely to travel have a 3026 consistent value. 3028 The default for any L2TP implementation is that UDP checksums MUST be 3029 enabled for both control and data messages. An L2TP implementation 3030 MAY provide an option to disable UDP checksums for data messages. It 3031 is recommended that UDP checksums always be enabled on control 3032 packets. 3034 Port 1701 is used for both L2F [RFC2341] and L2TP packets. The 3035 Version field in each header may be used to discriminate between the 3036 two packet types (L2F uses a value of 1, and the L2TP version 3037 described in this document uses a value of 2). An L2TP implementation 3038 running on a system which does not support L2F MUST silently discard 3039 all L2F packets. 3041 To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP link has 3042 the characteristic of being able to reorder or silently drop packets. 3043 The former may break non-IP protocols being carried by PPP, 3044 especially LAN-centric ones such as bridging. The latter may break 3045 protocols which assume per-packet indication of error, such as TCP 3046 header compression. Sequencing may be handled by using L2TP data 3047 message sequence numbers if any protocol being transported by the PPP 3048 tunnel cannot tolerate reordering. The sequence dependency 3049 characteristics of individual protocols are outside the scope of this 3050 document. 3052 Allowing packets to be dropped silently is perhaps more problematic 3053 with some protocols. If PPP reliable delivery [RFC1663] is enabled, 3054 no upper PPP protocol will encounter lost packets. If L2TP sequence 3055 numbers are enabled, L2TP can detect the packet loss. In the case of 3056 an LNS, the PPP and L2TP stacks are both present within the LNS, and 3057 packet loss signaling may occur precisely as if a packet was received 3058 with a CRC error. Where the LAC and PPP stack are co-resident, this 3059 technique also applies. Where the LAC and PPP client are physically 3060 distinct, the analogous signaling MAY be accomplished by sending a 3061 packet with a CRC error to the PPP client. Note that this would 3062 greatly increase the complexity of debugging client line problems, 3063 since the client statistics could not distinguish between true media 3064 errors and LAC-initiated ones. Further, this technique is not 3065 possible on all hardware. 3067 If VJ comprssion is used, and neither PPP reliable delivery nor 3068 sequence numbers are enabled, each lost packet results in a 1 in 3069 2**16 chance of a TCP segment being forwarded with incorrect contents 3070 [RFC1144]. Where the combination of the packet loss rate with this 3071 statistical exposure is unacceptable, TCP header compression SHOULD 3072 NOT be used. 3074 In general, it is wise to remember that the L2TP/UDP/IP transport is 3075 an unreliable transport. As with any PPP media that is subject to 3076 loss, care should be taken when using protocols that are particularly 3077 loss-sensitive. Such protocols include compression and encryption 3078 protocols that employ history. 3080 8.2 IP 3082 When operating in IP environments, L2TP MUST offer the UDP 3083 encapsulation described in 8.1 as its default configuration for IP 3084 operation. Other configurations (perhaps corresponding to a 3085 compressed header format) MAY be defined and made available as a 3086 configurable option. 3088 9.0 Security Considerations 3090 L2TP encounters several security issues in its operation. The 3091 general approach of L2TP to these issues is documented here. 3093 9.1 Tunnel Endpoint Security 3095 The tunnel endpoints may optionally perform an authentication 3096 procedure of one another during tunnel establishment. This 3097 authentication has the same security attributes as CHAP, and has 3098 reasonable protection against replay and snooping during the tunnel 3099 establishment process. This mechanism is not designed to provide any 3100 authentication beyond tunnel establishment; it is fairly simple for a 3101 malicious user who can snoop the tunnel stream to inject packets once 3102 an authenticated tunnel establishment has been completed 3103 successfully. 3105 For authentication to occur, the LAC and LNS MUST share a single 3106 secret. Each side uses this same secret when acting as authenticatee 3107 as well as authenticator. Since a single secret is used, the tunnel 3108 authentication AVPs include differentiating values in the CHAP ID 3109 fields for each message digest calculation to guard against replay 3110 attacks. 3112 The Assigned Tunnel ID and Assigned Session ID (See Section 4.4.3) 3113 SHOULD be selected in an unpredictable manner rather than 3114 sequentially or otherwise. Doing so will help deter hijacking of a 3115 session by a malicious user who does not have access to packet traces 3116 between the LAC and LNS. 3118 9.2 Packet Level Security 3120 Securing L2TP requires that the underlying transport make available 3121 encryption, integrity and authentication services for all L2TP 3122 traffic. This secure transport operates on the entire L2TP packet 3123 and is functionally independent of PPP and the protocol being carried 3124 by PPP. As such, L2TP is only concerned with confidentiality, 3125 wuthenticity, and integrity of the L2TP packets between its tunnel 3126 endpoints (the LAC and LNS), not unlike link-layer encryption being 3127 concerned only about protecting the confidentiality of traffic 3128 between its physical endpoints. 3130 9.3 End to End Security 3132 Protecting the L2TP packet stream via a secure transport does, in 3133 turn, also protect the data within the tunneled PPP packets while 3134 transported from the LAC to the LNS. Such protection should not be 3135 considered a substitution for end-to-end security between 3136 communicating hosts or applications. 3138 9.4 L2TP and IPsec 3140 When running over IP, IPsec provides packet-level security via ESP 3141 and/or AH. All L2TP control and data packets for a particular tunnel 3142 appear as homogeneous UDP/IP data packets to the IPsec system. 3144 In addition to IP transport security, IPsec defines a mode of 3145 operation that allows tunnelling of IP packets. The packet level 3146 encryption and authentication provided by IPsec tunnel mode and that 3147 provided by L2TP secured with IPsec provide an equivalent level of 3148 security for these requirements. 3150 IPsec also defines access control features that are required of a 3151 compliant IPsec implementation. These features allow filtering of 3152 packets based upon network and transport layer characteristics such 3153 as IP address, ports, etc. In the L2TP tunnelling model, analogous 3154 filtering is logically performed at the PPP layer or network layer 3155 above L2TP. These network layer access control features may be 3156 handled at the LNS via vendor-specific authorization features based 3157 upon the authenticated PPP user, or at the network layer itself by 3158 using IPsec transport mode end-to-end between the communicating 3159 hosts. The requirements for access control mechanisms are not a part 3160 of the L2TP specification and as such are outside the scope of this 3161 document. 3163 9.5 Proxy PPP Authentication 3165 L2TP defines AVPs that MAY be exchanged during session establishment 3166 to provide forwarding of PPP authentication information obtained at 3167 the LAC to the LNS for validation (see Section 4.4.5). This implies a 3168 direct trust relationship of the LAC on behalf of the LNS. If the 3169 LNS chooses to implement proxy authentication, it MUST be able to be 3170 configured off, requiring a new round a PPP authentication initiated 3171 by the LNS (which may or may not include a new round of LCP 3172 negotiation). 3174 10.0 IANA Considerations 3176 This document defines a number of "magic" numbers to be maintained by 3177 the IANA. This section explains the criteria to be used by the IANA 3178 to assign additional numbers in each of these lists. The following 3179 subsections describe the assignment policy for the namespaces defined 3180 elsewhere in this document. 3182 10.1 AVP Attributes 3184 As defined in Section 4.1, AVPs contain vendor ID, Attribute and 3185 Value fields. For vendor ID value of 0, IANA will maintain a registry 3186 of assigned Attributes and in some case also values. Attributes 0-39 3187 are assigned as defined in Section 4.4. The remaining values are 3188 available for assignment through IETF Consensus [RFC 2434]. 3190 10.2 Message Type AVP Values 3192 As defined in Section 4.4.1, Message Type AVPs (Attribute Type 0) 3193 have an associated value maintained by IANA. Values 0-16 are defined 3194 in Section 3.2, the remaining values are available for assignment via 3195 IETF Consensus [RFC 2434] 3197 10.3 Result Code AVP Values 3199 As defined in Section 4.4.2, Result Code AVPs (Attribute Type 1) 3200 contain three fields. Two of these fields (the Result Code and Error 3201 Code fields) have associated values maintained by IANA. 3203 10.3.1 Result Code Field Values 3205 The Result Code AVP may be included in CDN and StopCCN messages. The 3206 allowable values for the Result Code field of the AVP differ 3207 depending upon the value of the Message Type AVP. For the StopCCN 3208 message, values 0-7 are defined in Section 4.4.2; for the StopCCN 3209 message, values 0-11 are defined in the same section. The remaining 3210 values of the Result Code field for both messages are available for 3211 assignment via IETF Consensus [RFC 2434]. 3213 10.3.2 Error Code Field Values 3215 Values 0-7 are defined in Section 4.4.2. Values 8-32767 are 3216 available for assignment via IETF Consensus [RFC 2434]. The remaining 3217 values of the Error Code field are available for assignment via First 3218 Come First Served [RFC 2434]. 3220 10.4 Framing Capabilities & Bearer Capabilities 3222 The Framing Capabilities AVP and Bearer Capabilities AVPs (defined in 3223 Section 4.4.3) both contain 32-bit bitmasks. Additional bits should 3224 only be defined via a Standards Action [RFC 2434]. 3226 10.5 Proxy Authen Type AVP Values 3228 The Proxy Authen Type AVP (Attribute Type 29) has an associated value 3229 maintained by IANA. Values 0-5 are defined in Section 4.4.5, the 3230 remaining values are available for assignment via First Come First 3231 Served [RFC 2434]. 3233 10.6 AVP Header Bits 3235 There are four remaining reserved bits in the AVP header. Additional 3236 bits should only be assigned via a Standards Action [RFC 2434]. 3238 11.0 References 3240 [DSS1]ITU-T Recommendation, "Digital subscriber Signaling System No. 1 3241 (DSS 1) - ISDN user-network interface layer 3 specification for 3242 basic call control", Rec. Q.931(I.451), May 1998 3244 [KPS]Kaufman, C., Perlman, R., and Speciner, M., "Network Security: 3245 Private Communications in a Public World", Prentice Hall, March 3246 1995, ISBN 0-13-061466-1 3248 [PPTP]K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn, 3249 "Point-to-Point Tunneling Protocol (PPTP)", ``work in progress'', 3250 October 1998 3252 [RFC791] 3253 Postel, J., Internet Protocol, STD 5, RFC 791, September 1981 3255 [RFC1034] 3256 Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, 3257 RFC 1034, November 1987 3259 [RFC1144] 3260 Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial 3261 Links", RFC 1144, February 1990 3263 [RFC1661] 3264 Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 3265 July 1994 3267 [RFC1662] 3268 Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 3269 1994 3271 [RFC1663] 3272 Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994 3274 [RFC1700] 3275 Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 3276 October 1994 3278 [RFC1990] 3279 Sklower, K., et al., "The PPP Multilink Protocol (MP)", RFC 1990, 3280 August 1996 3282 [RFC1994] 3283 Simpson, W., "PPP Challenge Handshake Authentication Protocol 3284 (CHAP)", RFC 1994, August 1996 3286 [RFC1918] 3287 Rekhter, Y., et al., Address Allocation for Private Internets, BCP 3288 5, RFC 1918, February 1996 3290 [RFC2119] 3291 Bradner, S., "Key words for use in RFCs to Indicate Requirement 3292 Levels", BCP 14, RFC 2119, March 1997 3294 [RFC2138] 3295 Rigney, C., et al., "Remote Authentication Dial In User Service 3296 (RADIUS)", RFC 2138, April 1997 3298 [RFC2277] 3299 Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 3300 18, RFC 2277, January 1998 3302 [RFC2341] 3303 Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two Forward- 3304 ing (Protocol) L2F", RFC 2341, May 1998 3306 [RFC2434] 3307 Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Con- 3308 siderations Section in RFCs", BCP 26, RFC 2434, October 1998 3310 [RFC2401] 3311 Kent, S., Atkinson, R., "Security Architecture for the Internet 3312 Protocol", RFC 2401, November 1998 3314 [STEVENS] 3315 Stevens, W. Richard, "TCP/IP Illustrated, Volume I The Protocols", 3316 Addison-Wesley Publishing Company, Inc., March 1996, ISBN 3317 0-201-63346-9 3319 12.0 Acknowledgments 3321 The basic concept for L2TP and many of its protocol constructs were 3322 adopted from L2F [RFC2341] and PPTP [PPTP]. Authors of these are A. 3323 Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein, 3324 J. Taarud, W. Little, and G. Zorn. 3326 Dory Leifer made valuable refinements to the protocol definition of 3327 L2TP and contributed to the editing of this document. 3329 Steve Cobb and Evan Caves redesigned the state machine tables. 3331 Barney Wolff provided a great deal of design input on the endpoint 3332 authentication mechanism. 3334 John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, 3335 Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and 3336 review at the 43rd IETF in Orlando, FL., which led to improvement of 3337 the overall readability and clarity of this document. 3339 13.0 Author's Addresses 3341 Gurdeep Singh Pall 3342 Microsoft Corporation 3343 Redmond, WA 3344 gurdeep@microsoft.com 3346 Bill Palter 3347 RedBack Networks, Inc 3348 1389 Moffett Park Drive 3349 Sunnyvale, CA 94089 3350 palter@zev.net 3352 Allan Rubens 3353 Ascend Communications 3354 1701 Harbor Bay Parkway 3355 Alameda, CA 94502 3356 acr@del.com 3358 W. Mark Townsley 3359 cisco Systems 3360 7025 Kit Creek Road 3361 PO Box 14987 3362 Research Triangle Park, NC 27709 3363 townsley@cisco.com 3365 Andrew J. Valencia 3366 cisco Systems 3367 170 West Tasman Drive 3368 San Jose CA 95134-1706 3369 vandys@cisco.com 3371 Glen Zorn 3372 Microsoft Corporation 3373 One Microsoft Way 3374 Redmond, WA 98052 3375 gwz@acm.org 3377 Appendix A: Control Channel Slow Start and Congestion Avoidance 3379 Although each side has indicated the maximum size of its receive win- 3380 dow, it is recommended that a slow start and congestion avoidance 3381 method be used to transmit control packets. The methods described 3382 here are based upon the TCP congestion avoidance algorithm as 3383 described in section 21.6 of TCP/IP Illustrated, Volume I, by W. 3384 Richard Stevens [STEVENS]. 3386 Slow start and congestion avoidance make use of several variables. 3387 The congestion window (CWND) defines the number of packets a sender 3388 may send before waiting for an acknowledgment. The size of CWND 3389 expands and contracts as described below. Note however, that CWND is 3390 never allowed to exceed the size of the advertised window obtained 3391 from the Receive Window AVP (in the text below, it is assumed any 3392 increase will be limited by the Receive Window Size). The variable 3393 SSTHRESH determines when the sender switches from slow start to 3394 congestion avoidance. Slow start is used while CWND is less than 3395 SSHTRESH. 3397 A sender starts out in the slow start phase. CWND is initialized to 3398 one packet, and SSHTRESH is initialized to the advertised window 3399 (obtained from the Receive Window AVP). The sender then transmits 3400 one packet and waits for its acknowledgement (either explicit or pig- 3401 gybacked). When the acknowledgement is received, the congestion win- 3402 dow is incremented from one to two. During slow start, CWND is 3403 increased by one packet each time an ACK (explicit ZLB or pig- 3404 gybacked) is received. Increasing CWND by one on each ACK has the 3405 effect of doubling CWND with each round trip, resulting in an 3406 exponential increase. When the value of CWND reaches SSHTRESH, the 3407 slow start phase ends and the congestion avoidance phase begins. 3409 During congestion avoidance, CWND expands more slowly. Specifically, 3410 it increases by 1/CWND for every new ACK received. That is, CWND is 3411 increased by one packet after CWND new ACKs have been received. Win- 3412 dow expansion during the congestion avoidance phase is effectively 3413 linear, with CWND increasing by one packet each round trip. 3415 When congestion occurs (indicated by the triggering of a retransmis- 3416 sion) one half of the CWND is saved in SSTHRESH, and CWND is set to 3417 one. The sender then reenters the slow start phase. 3419 Appendix B: Control Message Examples 3420 B.1: Lock-step tunnel establishment 3422 In this example, an LAC establishes a tunnel, with the exchange 3423 involving each side alternating in sending messages. This example 3424 shows the final acknowledgment explicitly sent within a ZLB ACK 3425 message. An alternative would be to piggyback the acknowledgement 3426 within a message sent as a reply to the ICRQ or OCRQ that will 3427 likely follow from the side that initiated the tunnel. 3429 LAC or LNS LNS or LAC 3430 ---------- ---------- 3432 SCCRQ -> 3433 Nr: 0, Ns: 0 3434 <- SCCRP 3435 Nr: 1, Ns: 0 3436 SCCCN -> 3437 Nr: 1, Ns: 1 3438 <- ZLB 3439 Nr: 2, Ns: 1 3441 B.2: Lost packet with retransmission 3443 An existing tunnel has a new session requested by the LAC. The ICRP 3444 is lost and must be retransmitted by the LNS. Note that loss of the 3445 ICRP has two impacts: not only does it keep the upper level state 3446 machine from progressing, but it also keeps the LAC from seeing a 3447 timely lower level acknowledgment of its ICRQ. 3449 LAC LNS 3450 --- --- 3452 ICRQ -> 3453 Nr: 1, Ns: 2 3455 (packet lost) <- ICRP 3456 Nr: 3, Ns: 1 3458 (pause; LAC's timer started first, so fires first) 3460 ICRQ -> 3461 Nr: 1, Ns: 2 3463 (LNS realizes it has already seen this 3464 packet and discards it.) 3466 (LNS's timer fires.) 3467 <- ICRP 3468 Nr: 3, Ns: 1 3469 ICCN -> 3470 Nr: 2, Ns: 3 3472 <- ZLB 3473 Nr: 4, Ns: 2 3475 Appendix C: Intellectual Property Notice 3477 The IETF takes no position regarding the validity or scope of any 3478 intellectual property or other rights that might be claimed to per- 3479 tain to the implementation or use of the technology described in this 3480 document or the extent to which any license under such rights might 3481 or might not be available; neither does it represent that it has made 3482 any effort to identify any such rights. Information on the IETF's 3483 procedures with respect to rights in standards-track and standards- 3484 related documentation can be found in BCP-11. Copies of claims of 3485 rights made available for publication and any assurances of licenses 3486 to be made available, or the result of an attempt made to obtain a 3487 general license or permission for the use of such proprietary rights 3488 by implementors or users of this specification can be obtained from 3489 the IETF Secretariat." 3491 The IETF invites any interested party to bring to its attention any 3492 copyrights, patents or patent applications, or other proprietary 3493 rights which may cover technology that may be required to practice 3494 this standard. Please address the information to the IETF Executive 3495 Director. 3497 The IETF has been notified of intellectual property rights claimed in 3498 regard to some or all of the specification contained in this docu- 3499 ment. For more information consult the online list of claimed 3500 rights.