1 2 3 4 5 6 7Network Working Group W. Townsley 8Request for Comments: 2661 A. Valencia 9Category: Standards Track cisco Systems 10 A. Rubens 11 Ascend Communications 12 G. Pall 13 G. Zorn 14 Microsoft Corporation 15 B. Palter 16 Redback Networks 17 August 1999 18 19 20 Layer Two Tunneling Protocol "L2TP" 21 22Status of this Memo 23 24 This document specifies an Internet standards track protocol for the 25 Internet community, and requests discussion and suggestions for 26 improvements. Please refer to the current edition of the "Internet 27 Official Protocol Standards" (STD 1) for the standardization state 28 and status of this protocol. Distribution of this memo is unlimited. 29 30Copyright Notice 31 32 Copyright (C) The Internet Society (1999). All Rights Reserved. 33 34Abstract 35 36 This document describes the Layer Two Tunneling Protocol (L2TP). STD 37 51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP 38 facilitates the tunneling of PPP packets across an intervening 39 network in a way that is as transparent as possible to both end-users 40 and applications. 41 42Table of Contents 43 44 1.0 Introduction.......................................... 3 45 1.1 Specification of Requirements......................... 4 46 1.2 Terminology........................................... 4 47 2.0 Topology.............................................. 8 48 3.0 Protocol Overview..................................... 9 49 3.1 L2TP Header Format.................................... 9 50 3.2 Control Message Types................................. 11 51 4.0 Control Message Attribute Value Pairs................. 12 52 4.1 AVP Format............................................ 13 53 4.2 Mandatory AVPs........................................ 14 54 4.3 Hiding of AVP Attribute Values........................ 14 55 56 57 58Townsley, et al. Standards Track [Page 1] 59 60RFC 2661 L2TP August 1999 61 62 63 4.4 AVP Summary........................................... 17 64 4.4.1 AVPs Applicable To All Control Messages.......... 17 65 4.4.2 Result and Error Codes........................... 18 66 4.4.3 Control Connection Management AVPs............... 20 67 4.4.4 Call Management AVPs............................. 27 68 4.4.5 Proxy LCP and Authentication AVPs................ 34 69 4.4.6 Call Status AVPs................................. 39 70 5.0 Protocol Operation.................................... 41 71 5.1 Control Connection Establishment...................... 41 72 5.1.1 Tunnel Authentication............................ 42 73 5.2 Session Establishment................................. 42 74 5.2.1 Incoming Call Establishment...................... 42 75 5.2.2 Outgoing Call Establishment...................... 43 76 5.3 Forwarding PPP Frames................................. 43 77 5.4 Using Sequence Numbers on the Data Channel............ 44 78 5.5 Keepalive (Hello)..................................... 44 79 5.6 Session Teardown...................................... 45 80 5.7 Control Connection Teardown........................... 45 81 5.8 Reliable Delivery of Control Messages................. 46 82 6.0 Control Connection Protocol Specification............. 48 83 6.1 Start-Control-Connection-Request (SCCRQ).............. 48 84 6.2 Start-Control-Connection-Reply (SCCRP)................ 48 85 6.3 Start-Control-Connection-Connected (SCCCN)............ 49 86 6.4 Stop-Control-Connection-Notification (StopCCN)........ 49 87 6.5 Hello (HELLO)......................................... 49 88 6.6 Incoming-Call-Request (ICRQ).......................... 50 89 6.7 Incoming-Call-Reply (ICRP)............................ 51 90 6.8 Incoming-Call-Connected (ICCN)........................ 51 91 6.9 Outgoing-Call-Request (OCRQ).......................... 52 92 6.10 Outgoing-Call-Reply (OCRP)........................... 53 93 6.11 Outgoing-Call-Connected (OCCN)....................... 53 94 6.12 Call-Disconnect-Notify (CDN)......................... 53 95 6.13 WAN-Error-Notify (WEN)............................... 54 96 6.14 Set-Link-Info (SLI).................................. 54 97 7.0 Control Connection State Machines..................... 54 98 7.1 Control Connection Protocol Operation................. 55 99 7.2 Control Connection States............................. 56 100 7.2.1 Control Connection Establishment................. 56 101 7.3 Timing considerations................................. 58 102 7.4 Incoming calls........................................ 58 103 7.4.1 LAC Incoming Call States......................... 60 104 7.4.2 LNS Incoming Call States......................... 62 105 7.5 Outgoing calls........................................ 63 106 7.5.1 LAC Outgoing Call States......................... 64 107 7.5.2 LNS Outgoing Call States......................... 66 108 7.6 Tunnel Disconnection.................................. 67 109 8.0 L2TP Over Specific Media.............................. 67 110 8.1 L2TP over UDP/IP...................................... 68 111 112 113 114Townsley, et al. Standards Track [Page 2] 115 116RFC 2661 L2TP August 1999 117 118 119 8.2 IP.................................................... 69 120 9.0 Security Considerations............................... 69 121 9.1 Tunnel Endpoint Security.............................. 70 122 9.2 Packet Level Security................................. 70 123 9.3 End to End Security................................... 70 124 9.4 L2TP and IPsec........................................ 71 125 9.5 Proxy PPP Authentication.............................. 71 126 10.0 IANA Considerations.................................. 71 127 10.1 AVP Attributes....................................... 71 128 10.2 Message Type AVP Values.............................. 72 129 10.3 Result Code AVP Values............................... 72 130 10.3.1 Result Code Field Values........................ 72 131 10.3.2 Error Code Field Values......................... 72 132 10.4 Framing Capabilities & Bearer Capabilities........... 72 133 10.5 Proxy Authen Type AVP Values......................... 72 134 10.6 AVP Header Bits...................................... 73 135 11.0 References........................................... 73 136 12.0 Acknowledgments...................................... 74 137 13.0 Authors' Addresses................................... 75 138 Appendix A: Control Channel Slow Start and Congestion 139 Avoidance..................................... 76 140 Appendix B: Control Message Examples...................... 77 141 Appendix C: Intellectual Property Notice.................. 79 142 Full Copyright Statement.................................. 80 143 1441.0 Introduction 145 146 PPP [RFC1661] defines an encapsulation mechanism for transporting 147 multiprotocol packets across layer 2 (L2) point-to-point links. 148 Typically, a user obtains a L2 connection to a Network Access Server 149 (NAS) using one of a number of techniques (e.g., dialup POTS, ISDN, 150 ADSL, etc.) and then runs PPP over that connection. In such a 151 configuration, the L2 termination point and PPP session endpoint 152 reside on the same physical device (i.e., the NAS). 153 154 L2TP extends the PPP model by allowing the L2 and PPP endpoints to 155 reside on different devices interconnected by a packet-switched 156 network. With L2TP, a user has an L2 connection to an access 157 concentrator (e.g., modem bank, ADSL DSLAM, etc.), and the 158 concentrator then tunnels individual PPP frames to the NAS. This 159 allows the actual processing of PPP packets to be divorced from the 160 termination of the L2 circuit. 161 162 One obvious benefit of such a separation is that instead of requiring 163 the L2 connection terminate at the NAS (which may require a 164 long-distance toll charge), the connection may terminate at a (local) 165 circuit concentrator, which then extends the logical PPP session over 166 167 168 169 170Townsley, et al. Standards Track [Page 3] 171 172RFC 2661 L2TP August 1999 173 174 175 a shared infrastructure such as frame relay circuit or the Internet. 176 From the user's perspective, there is no functional difference between 177 having the L2 circuit terminate in a NAS directly or using L2TP. 178 179 L2TP may also solve the multilink hunt-group splitting problem. 180 Multilink PPP [RFC1990] requires that all channels composing a 181 multilink bundle be grouped at a single Network Access Server (NAS). 182 Due to its ability to project a PPP session to a location other than 183 the point at which it was physically received, L2TP can be used to 184 make all channels terminate at a single NAS. This allows multilink 185 operation even when the calls are spread across distinct physical 186 NASs. 187 188 This document defines the necessary control protocol for on-demand 189 creation of tunnels between two nodes and the accompanying 190 encapsulation for multiplexing multiple, tunneled PPP sessions. 191 1921.1 Specification of Requirements 193 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in [RFC2119]. 197 1981.2 Terminology 199 200 Analog Channel 201 202 A circuit-switched communication path which is intended to carry 203 3.1 kHz audio in each direction. 204 205 Attribute Value Pair (AVP) 206 207 The variable length concatenation of a unique Attribute 208 (represented by an integer) and a Value containing the actual 209 value identified by the attribute. Multiple AVPs make up Control 210 Messages which are used in the establishment, maintenance, and 211 teardown of tunnels. 212 213 Call 214 215 A connection (or attempted connection) between a Remote System and 216 LAC. For example, a telephone call through the PSTN. A Call 217 (Incoming or Outgoing) which is successfully established between a 218 Remote System and LAC results in a corresponding L2TP Session 219 within a previously established Tunnel between the LAC and LNS. 220 (See also: Session, Incoming Call, Outgoing Call). 221 222 223 224 225 226Townsley, et al. Standards Track [Page 4] 227 228RFC 2661 L2TP August 1999 229 230 231 Called Number 232 233 An indication to the receiver of a call as to what telephone 234 number the caller used to reach it. 235 236 Calling Number 237 238 An indication to the receiver of a call as to the telephone number 239 of the caller. 240 241 CHAP 242 243 Challenge Handshake Authentication Protocol [RFC1994], a PPP 244 cryptographic challenge/response authentication protocol in which 245 the cleartext password is not passed over the line. 246 247 Control Connection 248 249 A control connection operates in-band over a tunnel to control the 250 establishment, release, and maintenance of sessions and of the 251 tunnel itself. 252 253 Control Messages 254 255 Control messages are exchanged between LAC and LNS pairs, 256 operating in-band within the tunnel protocol. Control messages 257 govern aspects of the tunnel and sessions within the tunnel. 258 259 Digital Channel 260 261 A circuit-switched communication path which is intended to carry 262 digital information in each direction. 263 264 DSLAM 265 266 Digital Subscriber Line (DSL) Access Module. A network device used 267 in the deployment of DSL service. This is typically a concentrator 268 of individual DSL lines located in a central office (CO) or local 269 exchange. 270 271 Incoming Call 272 273 A Call received at an LAC to be tunneled to an LNS (see Call, 274 Outgoing Call). 275 276 277 278 279 280 281 282Townsley, et al. Standards Track [Page 5] 283 284RFC 2661 L2TP August 1999 285 286 287 L2TP Access Concentrator (LAC) 288 289 A node that acts as one side of an L2TP tunnel endpoint and is a 290 peer to the L2TP Network Server (LNS). The LAC sits between an 291 LNS and a remote system and forwards packets to and from each. 292 Packets sent from the LAC to the LNS requires tunneling with the 293 L2TP protocol as defined in this document. The connection from 294 the LAC to the remote system is either local (see: Client LAC) or 295 a PPP link. 296 297 L2TP Network Server (LNS) 298 299 A node that acts as one side of an L2TP tunnel endpoint and is a 300 peer to the L2TP Access Concentrator (LAC). The LNS is the 301 logical termination point of a PPP session that is being tunneled 302 from the remote system by the LAC. 303 304 Management Domain (MD) 305 306 A network or networks under the control of a single 307 administration, policy or system. For example, an LNS's Management 308 Domain might be the corporate network it serves. An LAC's 309 Management Domain might be the Internet Service Provider that owns 310 and manages it. 311 312 Network Access Server (NAS) 313 314 A device providing local network access to users across a remote 315 access network such as the PSTN. An NAS may also serve as an LAC, 316 LNS or both. 317 318 Outgoing Call 319 320 A Call placed by an LAC on behalf of an LNS (see Call, Incoming 321 Call). 322 323 Peer 324 325 When used in context with L2TP, peer refers to either the LAC or 326 LNS. An LAC's Peer is an LNS and vice versa. When used in context 327 with PPP, a peer is either side of the PPP connection. 328 329 POTS 330 331 Plain Old Telephone Service. 332 333 334 335 336 337 338Townsley, et al. Standards Track [Page 6] 339 340RFC 2661 L2TP August 1999 341 342 343 Remote System 344 345 An end-system or router attached to a remote access network (i.e. 346 a PSTN), which is either the initiator or recipient of a call. 347 Also referred to as a dial-up or virtual dial-up client. 348 349 Session 350 351 L2TP is connection-oriented. The LNS and LAC maintain state for 352 each Call that is initiated or answered by an LAC. An L2TP Session 353 is created between the LAC and LNS when an end-to-end PPP 354 connection is established between a Remote System and the LNS. 355 Datagrams related to the PPP connection are sent over the Tunnel 356 between the LAC and LNS. There is a one to one relationship 357 between established L2TP Sessions and their associated Calls. (See 358 also: Call). 359 360 Tunnel 361 362 A Tunnel exists between a LAC-LNS pair. The Tunnel consists of a 363 Control Connection and zero or more L2TP Sessions. The Tunnel 364 carries encapsulated PPP datagrams and Control Messages between 365 the LAC and the LNS. 366 367 Zero-Length Body (ZLB) Message 368 369 A control packet with only an L2TP header. ZLB messages are used 370 for explicitly acknowledging packets on the reliable control 371 channel. 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394Townsley, et al. Standards Track [Page 7] 395 396RFC 2661 L2TP August 1999 397 398 3992.0 Topology 400 401 The following diagram depicts a typical L2TP scenario. The goal is to 402 tunnel PPP frames between the Remote System or LAC Client and an LNS 403 located at a Home LAN. 404 405 [Home LAN] 406 [LAC Client]----------+ | 407 ____|_____ +--[Host] 408 | | | 409 [LAC]---------| Internet |-----[LNS]-----+ 410 | |__________| | 411 _____|_____ : 412 | | 413 | PSTN | 414 [Remote]--| Cloud | 415 [System] | | [Home LAN] 416 |___________| | 417 | ______________ +---[Host] 418 | | | | 419 [LAC]-------| Frame Relay |---[LNS]-----+ 420 | or ATM Cloud | | 421 |______________| : 422 423 The Remote System initiates a PPP connection across the PSTN Cloud to 424 an LAC. The LAC then tunnels the PPP connection across the Internet, 425 Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN is 426 obtained. The Remote System is provided addresses from the HOME LAN 427 428 via PPP NCP negotiation. Authentication, Authorization and Accounting 429 may be provided by the Home LAN's Management Domain as if the user 430 were connected to a Network Access Server directly. 431 432 A LAC Client (a Host which runs L2TP natively) may also participate 433 in tunneling to the Home LAN without use of a separate LAC. In this 434 case, the Host containing the LAC Client software already has a 435 connection to the public Internet. A "virtual" PPP connection is then 436 created and the local L2TP LAC Client software creates a tunnel to 437 the LNS. As in the above case, Addressing, Authentication, 438 Authorization and Accounting will be provided by the Home LAN's 439 Management Domain. 440 441 442 443 444 445 446 447 448 449 450Townsley, et al. Standards Track [Page 8] 451 452RFC 2661 L2TP August 1999 453 454 4553.0 Protocol Overview 456 457 L2TP utilizes two types of messages, control messages and data 458 messages. Control messages are used in the establishment, maintenance 459 and clearing of tunnels and calls. Data messages are used to 460 encapsulate PPP frames being carried over the tunnel. Control 461 messages utilize a reliable Control Channel within L2TP to guarantee 462 delivery (see section 5.1 for details). Data messages are not 463 retransmitted when packet loss occurs. 464 465 +-------------------+ 466 | PPP Frames | 467 +-------------------+ +-----------------------+ 468 | L2TP Data Messages| | L2TP Control Messages | 469 +-------------------+ +-----------------------+ 470 | L2TP Data Channel | | L2TP Control Channel | 471 | (unreliable) | | (reliable) | 472 +------------------------------------------------+ 473 | Packet Transport (UDP, FR, ATM, etc.) | 474 +------------------------------------------------+ 475 476 Figure 3.0 L2TP Protocol Structure 477 478 Figure 3.0 depicts the relationship of PPP frames and Control 479 Messages over the L2TP Control and Data Channels. PPP Frames are 480 passed over an unreliable Data Channel encapsulated first by an L2TP 481 header and then a Packet Transport such as UDP, Frame Relay, ATM, 482 etc. Control messages are sent over a reliable L2TP Control Channel 483 which transmits packets in-band over the same Packet Transport. 484 485 Sequence numbers are required to be present in all control messages 486 and are used to provide reliable delivery on the Control Channel. 487 Data Messages may use sequence numbers to reorder packets and detect 488 lost packets. 489 490 All values are placed into their respective fields and sent in 491 network order (high order octets first). 492 4933.1 L2TP Header Format 494 495 L2TP packets for the control channel and data channel share a common 496 header format. In each case where a field is optional, its space does 497 not exist in the message if the field is marked not present. Note 498 that while optional on data messages, the Length, Ns, and Nr fields 499 marked as optional below, are required to be present on all control 500 messages. 501 502 503 504 505 506Townsley, et al. Standards Track [Page 9] 507 508RFC 2661 L2TP August 1999 509 510 511 This header is formatted: 512 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Tunnel ID | Session ID | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Ns (opt) | Nr (opt) | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Offset Size (opt) | Offset pad... (opt) 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 525 Figure 3.1 L2TP Message Header 526 527 The Type (T) bit indicates the type of message. It is set to 0 for a 528 data message and 1 for a control message. 529 530 If the Length (L) bit is 1, the Length field is present. This bit 531 MUST be set to 1 for control messages. 532 533 The x bits are reserved for future extensions. All reserved bits MUST 534 be set to 0 on outgoing messages and ignored on incoming messages. 535 536 If the Sequence (S) bit is set to 1 the Ns and Nr fields are present. 537 The S bit MUST be set to 1 for control messages. 538 539 If the Offset (O) bit is 1, the Offset Size field is present. The O 540 bit MUST be set to 0 (zero) for control messages. 541 542 If the Priority (P) bit is 1, this data message should receive 543 preferential treatment in its local queuing and transmission. LCP 544 echo requests used as a keepalive for the link, for instance, should 545 generally be sent with this bit set to 1. Without it, a temporary 546 interval of local congestion could result in interference with 547 keepalive messages and unnecessary loss of the link. This feature is 548 only for use with data messages. The P bit MUST be set to 0 for all 549 control messages. 550 551 Ver MUST be 2, indicating the version of the L2TP data message header 552 described in this document. The value 1 is reserved to permit 553 detection of L2F [RFC2341] packets should they arrive intermixed with 554 L2TP packets. Packets received with an unknown Ver field MUST be 555 discarded. 556 557 The Length field indicates the total length of the message in octets. 558 559 560 561 562Townsley, et al. Standards Track [Page 10] 563 564RFC 2661 L2TP August 1999 565 566 567 Tunnel ID indicates the identifier for the control connection. L2TP 568 tunnels are named by identifiers that have local significance only. 569 That is, the same tunnel will be given different Tunnel IDs by each 570 end of the tunnel. Tunnel ID in each message is that of the intended 571 recipient, not the sender. Tunnel IDs are selected and exchanged as 572 Assigned Tunnel ID AVPs during the creation of a tunnel. 573 574 Session ID indicates the identifier for a session within a tunnel. 575 L2TP sessions are named by identifiers that have local significance 576 only. That is, the same session will be given different Session IDs 577 by each end of the session. Session ID in each message is that of the 578 intended recipient, not the sender. Session IDs are selected and 579 exchanged as Assigned Session ID AVPs during the creation of a 580 session. 581 582 Ns indicates the sequence number for this data or control message, 583 beginning at zero and incrementing by one (modulo 2**16) for each 584 message sent. See Section 5.8 and 5.4 for more information on using 585 this field. 586 587 Nr indicates the sequence number expected in the next control message 588 to be received. Thus, Nr is set to the Ns of the last in-order 589 message received plus one (modulo 2**16). In data messages, Nr is 590 reserved and, if present (as indicated by the S-bit), MUST be ignored 591 upon receipt. See section 5.8 for more information on using this 592 field in control messages. 593 594 The Offset Size field, if present, specifies the number of octets 595 past the L2TP header at which the payload data is expected to start. 596 Actual data within the offset padding is undefined. If the offset 597 field is present, the L2TP header ends after the last octet of the 598 offset padding. 599 6003.2 Control Message Types 601 602 The Message Type AVP (see section 4.4.1) defines the specific type of 603 control message being sent. Recall from section 3.1 that this is only 604 for control messages, that is, messages with the T-bit set to 1. 605 606 607 608 609 610 611 612 613 614 615 616 617 618Townsley, et al. Standards Track [Page 11] 619 620RFC 2661 L2TP August 1999 621 622 623 This document defines the following control message types (see 624 Section 6.1 through 6.14 for details on the construction and use of 625 each message): 626 627 Control Connection Management 628 629 0 (reserved) 630 631 1 (SCCRQ) Start-Control-Connection-Request 632 2 (SCCRP) Start-Control-Connection-Reply 633 3 (SCCCN) Start-Control-Connection-Connected 634 4 (StopCCN) Stop-Control-Connection-Notification 635 5 (reserved) 636 6 (HELLO) Hello 637 638 Call Management 639 640 7 (OCRQ) Outgoing-Call-Request 641 8 (OCRP) Outgoing-Call-Reply 642 9 (OCCN) Outgoing-Call-Connected 643 10 (ICRQ) Incoming-Call-Request 644 11 (ICRP) Incoming-Call-Reply 645 12 (ICCN) Incoming-Call-Connected 646 13 (reserved) 647 14 (CDN) Call-Disconnect-Notify 648 649 Error Reporting 650 651 15 (WEN) WAN-Error-Notify 652 653 PPP Session Control 654 655 16 (SLI) Set-Link-Info 656 6574.0 Control Message Attribute Value Pairs 658 659 To maximize extensibility while still permitting interoperability, a 660 uniform method for encoding message types and bodies is used 661 throughout L2TP. This encoding will be termed AVP (Attribute-Value 662 Pair) in the remainder of this document. 663 664 665 666 667 668 669 670 671 672 673 674Townsley, et al. Standards Track [Page 12] 675 676RFC 2661 L2TP August 1999 677 678 6794.1 AVP Format 680 681 Each AVP is encoded as: 682 683 0 1 2 3 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 |M|H| rsvd | Length | Vendor ID | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Attribute Type | Attribute Value... 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 [until Length is reached]... | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 693 The first six bits are a bit mask, describing the general attributes 694 of the AVP. 695 696 Two bits are defined in this document, the remaining are reserved for 697 future extensions. Reserved bits MUST be set to 0. An AVP received 698 with a reserved bit set to 1 MUST be treated as an unrecognized AVP. 699 700 Mandatory (M) bit: Controls the behavior required of an 701 implementation which receives an AVP which it does not recognize. If 702 the M bit is set on an unrecognized AVP within a message associated 703 with a particular session, the session associated with this message 704 MUST be terminated. If the M bit is set on an unrecognized AVP within 705 a message associated with the overall tunnel, the entire tunnel (and 706 all sessions within) MUST be terminated. If the M bit is not set, an 707 unrecognized AVP MUST be ignored. The control message must then 708 continue to be processed as if the AVP had not been present. 709 710 Hidden (H) bit: Identifies the hiding of data in the Attribute Value 711 field of an AVP. This capability can be used to avoid the passing of 712 sensitive data, such as user passwords, as cleartext in an AVP. 713 Section 4.3 describes the procedure for performing AVP hiding. 714 715 Length: Encodes the number of octets (including the Overall Length 716 and bitmask fields) contained in this AVP. The Length may be 717 calculated as 6 + the length of the Attribute Value field in octets. 718 The field itself is 10 bits, permitting a maximum of 1023 octets of 719 data in a single AVP. The minimum Length of an AVP is 6. If the 720 length is 6, then the Attribute Value field is absent. 721 722 Vendor ID: The IANA assigned "SMI Network Management Private 723 Enterprise Codes" [RFC1700] value. The value 0, corresponding to 724 IETF adopted attribute values, is used for all AVPs defined within 725 this document. Any vendor wishing to implement their own L2TP 726 extensions can use their own Vendor ID along with private Attribute 727 728 729 730Townsley, et al. Standards Track [Page 13] 731 732RFC 2661 L2TP August 1999 733 734 735 values, guaranteeing that they will not collide with any other 736 vendor's extensions, nor with future IETF extensions. Note that there 737 are 16 bits allocated for the Vendor ID, thus limiting this feature 738 to the first 65,535 enterprises. 739 740 Attribute Type: A 2 octet value with a unique interpretation across 741 all AVPs defined under a given Vendor ID. 742 743 Attribute Value: This is the actual value as indicated by the Vendor 744 ID and Attribute Type. It follows immediately after the Attribute 745 Type field, and runs for the remaining octets indicated in the Length 746 (i.e., Length minus 6 octets of header). This field is absent if the 747 Length is 6. 748 7494.2 Mandatory AVPs 750 751 Receipt of an unknown AVP that has the M-bit set is catastrophic to 752 the session or tunnel it is associated with. Thus, the M bit should 753 only be defined for AVPs which are absolutely crucial to proper 754 operation of the session or tunnel. Further, in the case where the 755 LAC or LNS receives an unknown AVP with the M-bit set and shuts down 756 the session or tunnel accordingly, it is the full responsibility of 757 the peer sending the Mandatory AVP to accept fault for causing an 758 non-interoperable situation. Before defining an AVP with the M-bit 759 set, particularly a vendor-specific AVP, be sure that this is the 760 intended consequence. 761 762 When an adequate alternative exists to use of the M-bit, it should be 763 utilized. For example, rather than simply sending an AVP with the M- 764 bit set to determine if a specific extension exists, availability may 765 be identified by sending an AVP in a request message and expecting a 766 corresponding AVP in a reply message. 767 768 Use of the M-bit with new AVPs (those not defined in this document) 769 MUST provide the ability to configure the associated feature off, 770 such that the AVP is either not sent, or sent with the M-bit not set. 771 7724.3 Hiding of AVP Attribute Values 773 774 The H bit in the header of each AVP provides a mechanism to indicate 775 to the receiving peer whether the contents of the AVP are hidden or 776 present in cleartext. This feature can be used to hide sensitive 777 control message data such as user passwords or user IDs. 778 779 The H bit MUST only be set if a shared secret exists between the LAC 780 and LNS. The shared secret is the same secret that is used for tunnel 781 authentication (see Section 5.1.1). If the H bit is set in any 782 783 784 785 786Townsley, et al. Standards Track [Page 14] 787 788RFC 2661 L2TP August 1999 789 790 791 AVP(s) in a given control message, a Random Vector AVP must also be 792 present in the message and MUST precede the first AVP having an H bit 793 of 1. 794 795 Hiding an AVP value is done in several steps. The first step is to 796 take the length and value fields of the original (cleartext) AVP and 797 encode them into a Hidden AVP Subformat as follows: 798 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Length of Original Value | Original Attribute Value ... 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 ... | Padding ... 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 807 Length of Original Attribute Value: This is length of the Original 808 Attribute Value to be obscured in octets. This is necessary to 809 determine the original length of the Attribute Value which is lost 810 when the additional Padding is added. 811 812 Original Attribute Value: Attribute Value that is to be obscured. 813 814 Padding: Random additional octets used to obscure length of the 815 Attribute Value that is being hidden. 816 817 To mask the size of the data being hidden, the resulting subformat 818 MAY be padded as shown above. Padding does NOT alter the value placed 819 in the Length of Original Attribute Value field, but does alter the 820 length of the resultant AVP that is being created. For example, If an 821 Attribute Value to be hidden is 4 octets in length, the unhidden AVP 822 length would be 10 octets (6 + Attribute Value length). After hiding, 823 the length of the AVP will become 6 + Attribute Value length + size 824 of the Length of Original Attribute Value field + Padding. Thus, if 825 Padding is 12 octets, the AVP length will be 6 + 4 + 2 + 12 = 24 826 octets. 827 828 Next, An MD5 hash is performed on the concatenation of: 829 830 + the 2 octet Attribute number of the AVP 831 + the shared secret 832 + an arbitrary length random vector 833 834 The value of the random vector used in this hash is passed in the 835 value field of a Random Vector AVP. This Random Vector AVP must be 836 placed in the message by the sender before any hidden AVPs. The same 837 random vector may be used for more than one hidden AVP in the same 838 839 840 841 842Townsley, et al. Standards Track [Page 15] 843 844RFC 2661 L2TP August 1999 845 846 847 message. If a different random vector is used for the hiding of 848 subsequent AVPs then a new Random Vector AVP must be placed in the 849 command message before the first AVP to which it applies. 850 851 The MD5 hash value is then XORed with the first 16 octet (or less) 852 segment of the Hidden AVP Subformat and placed in the Attribute Value 853 field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 854 octets, the Subformat is transformed as if the Attribute Value field 855 had been padded to 16 octets before the XOR, but only the actual 856 octets present in the Subformat are modified, and the length of the 857 AVP is not altered. 858 859 If the Subformat is longer than 16 octets, a second one-way MD5 hash 860 is calculated over a stream of octets consisting of the shared secret 861 followed by the result of the first XOR. That hash is XORed with the 862 second 16 octet (or less) segment of the Subformat and placed in the 863 corresponding octets of the Value field of the Hidden AVP. 864 865 If necessary, this operation is repeated, with the shared secret used 866 along with each XOR result to generate the next hash to XOR the next 867 segment of the value with. 868 869 The hiding method was adapted from RFC 2138 [RFC2138] which was taken 870 from the "Mixing in the Plaintext" section in the book "Network 871 Security" by Kaufman, Perlman and Speciner [KPS]. A detailed 872 explanation of the method follows: 873 874 Call the shared secret S, the Random Vector RV, and the Attribute 875 Value AV. Break the value field into 16-octet chunks p1, p2, etc. 876 with the last one padded at the end with random data to a 16-octet 877 boundary. Call the ciphertext blocks c(1), c(2), etc. We will also 878 define intermediate values b1, b2, etc. 879 880 b1 = MD5(AV + S + RV) c(1) = p1 xor b1 881 b2 = MD5(S + c(1)) c(2) = p2 xor b2 882 . . 883 . . 884 . . 885 bi = MD5(S + c(i-1)) c(i) = pi xor bi 886 887 The String will contain c(1)+c(2)+...+c(i) where + denotes 888 concatenation. 889 890 On receipt, the random vector is taken from the last Random Vector 891 AVP encountered in the message prior to the AVP to be unhidden. The 892 above process is then reversed to yield the original value. 893 894 895 896 897 898Townsley, et al. Standards Track [Page 16] 899 900RFC 2661 L2TP August 1999 901 902 9034.4 AVP Summary 904 905 The following sections contain a list of all L2TP AVPs defined in 906 this document. 907 908 Following the name of the AVP is a list indicating the message types 909 that utilize each AVP. After each AVP title follows a short 910 description of the purpose of the AVP, a detail (including a graphic) 911 of the format for the Attribute Value, and any additional information 912 needed for proper use of the avp. 913 9144.4.1 AVPs Applicable To All Control Messages 915 916 Message Type (All Messages) 917 918 The Message Type AVP, Attribute Type 0, identifies the control 919 message herein and defines the context in which the exact meaning 920 of the following AVPs will be determined. 921 922 The Attribute Value field for this AVP has the following format: 923 924 0 1 925 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Message Type | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 930 The Message Type is a 2 octet unsigned integer. 931 932 The Message Type AVP MUST be the first AVP in a message, 933 immediately following the control message header (defined in 934 section 3.1). See Section 3.2 for the list of defined control 935 message types and their identifiers. 936 937 The Mandatory (M) bit within the Message Type AVP has special 938 meaning. Rather than an indication as to whether the AVP itself 939 should be ignored if not recognized, it is an indication as to 940 whether the control message itself should be ignored. Thus, if the 941 M-bit is set within the Message Type AVP and the Message Type is 942 unknown to the implementation, the tunnel MUST be cleared. If the 943 M-bit is not set, then the implementation may ignore an unknown 944 message type. The M-bit MUST be set to 1 for all message types 945 defined in this document. This AVP may not be hidden (the H-bit 946 MUST be 0). The Length of this AVP is 8. 947 948 949 950 951 952 953 954Townsley, et al. Standards Track [Page 17] 955 956RFC 2661 L2TP August 1999 957 958 959 Random Vector (All Messages) 960 961 The Random Vector AVP, Attribute Type 36, is used to enable the 962 hiding of the Attribute Value of arbitrary AVPs. 963 964 The Attribute Value field for this AVP has the following format: 965 966 0 1 2 3 967 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 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Random Octet String ... 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 972 The Random Octet String may be of arbitrary length, although a 973 random vector of at least 16 octets is recommended. The string 974 contains the random vector for use in computing the MD5 hash to 975 retrieve or hide the Attribute Value of a hidden AVP (see Section 976 4.2). 977 978 More than one Random Vector AVP may appear in a message, in which 979 case a hidden AVP uses the Random Vector AVP most closely 980 preceding it. This AVP MUST precede the first AVP with the H bit 981 set. 982 983 The M-bit for this AVP MUST be set to 1. This AVP MUST NOT be 984 hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the 985 length of the Random Octet String. 986 9874.4.2 Result and Error Codes 988 989 Result Code (CDN, StopCCN) 990 991 The Result Code AVP, Attribute Type 1, indicates the reason for 992 terminating the control channel or session. 993 994 The Attribute Value field for this AVP has the following format: 995 996 0 1 2 3 997 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 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Result Code | Error Code (opt) | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | Error Message (opt) ... 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 1004 The Result Code is a 2 octet unsigned integer. The optional Error 1005 Code is a 2 octet unsigned integer. An optional Error Message can 1006 follow the Error Code field. Presence of the Error Code and 1007 1008 1009 1010Townsley, et al. Standards Track [Page 18] 1011 1012RFC 2661 L2TP August 1999 1013 1014 1015 Message are indicated by the AVP Length field. The Error Message 1016 contains an arbitrary string providing further (human readable) 1017 text associated with the condition. Human readable text in all 1018 error messages MUST be provided in the UTF-8 charset using the 1019 Default Language [RFC2277]. 1020 1021 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1022 this AVP MUST be set to 1. The Length is 8 if there is no Error 1023 Code or Message, 10 if there is an Error Code and no Error Message 1024 or 10 + the length of the Error Message if there is an Error Code 1025 and Message. 1026 1027 Defined Result Code values for the StopCCN message are: 1028 1029 0 - Reserved 1030 1 - General request to clear control connection 1031 2 - General error--Error Code indicates the problem 1032 3 - Control channel already exists 1033 4 - Requester is not authorized to establish a control 1034 channel 1035 5 - The protocol version of the requester is not 1036 supported 1037 Error Code indicates highest version supported 1038 6 - Requester is being shut down 1039 7 - Finite State Machine error 1040 1041 Defined Result Code values for the CDN message are: 1042 1043 0 - Reserved 1044 1 - Call disconnected due to loss of carrier 1045 2 - Call disconnected for the reason indicated 1046 in error code 1047 3 - Call disconnected for administrative reasons 1048 4 - Call failed due to lack of appropriate facilities 1049 being available (temporary condition) 1050 5 - Call failed due to lack of appropriate facilities being 1051 available (permanent condition) 1052 6 - Invalid destination 1053 7 - Call failed due to no carrier detected 1054 8 - Call failed due to detection of a busy signal 1055 9 - Call failed due to lack of a dial tone 1056 10 - Call was not established within time allotted by LAC 1057 11 - Call was connected but no appropriate framing was 1058 detected 1059 1060 The Error Codes defined below pertain to types of errors that are 1061 not specific to any particular L2TP request, but rather to 1062 protocol or message format errors. If an L2TP reply indicates in 1063 1064 1065 1066Townsley, et al. Standards Track [Page 19] 1067 1068RFC 2661 L2TP August 1999 1069 1070 1071 its Result Code that a general error occurred, the General Error 1072 value should be examined to determine what the error was. The 1073 currently defined General Error codes and their meanings are: 1074 1075 0 - No general error 1076 1 - No control connection exists yet for this LAC-LNS pair 1077 2 - Length is wrong 1078 3 - One of the field values was out of range or 1079 reserved field was non-zero 1080 4 - Insufficient resources to handle this operation now 1081 5 - The Session ID is invalid in this context 1082 6 - A generic vendor-specific error occurred in the LAC 1083 7 - Try another. If LAC is aware of other possible LNS 1084 destinations, it should try one of them. This can be 1085 used to guide an LAC based on LNS policy, for instance, 1086 the existence of multilink PPP bundles. 1087 8 - Session or tunnel was shutdown due to receipt of an unknown 1088 AVP with the M-bit set (see section 4.2). The Error Message 1089 SHOULD contain the attribute of the offending AVP in (human 1090 readable) text form. 1091 1092 When a General Error Code of 6 is used, additional information 1093 about the error SHOULD be included in the Error Message field. 1094 10954.4.3 Control Connection Management AVPs 1096 1097 Protocol Version (SCCRP, SCCRQ) 1098 1099 The Protocol Version AVP, Attribute Type 2, indicates the L2TP 1100 protocol version of the sender. 1101 1102 The Attribute Value field for this AVP has the following format: 1103 1104 0 1 1105 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Ver | Rev | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 1110 The Ver field is a 1 octet unsigned integer containing the value 1111 1. Rev field is a 1 octet unsigned integer containing 0. This 1112 pertains to L2TP protocol version 1, revision 0. Note this is not 1113 the same version number that is included in the header of each 1114 message. 1115 1116 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1117 this AVP MUST be set to 1. The Length of this AVP is 8. 1118 1119 1120 1121 1122Townsley, et al. Standards Track [Page 20] 1123 1124RFC 2661 L2TP August 1999 1125 1126 1127 Framing Capabilities (SCCRP, SCCRQ) 1128 1129 The Framing Capabilities AVP, Attribute Type 3, provides the peer 1130 with an indication of the types of framing that will be accepted 1131 or requested by the sender. 1132 1133 The Attribute Value field for this AVP has the following format: 1134 1135 0 1 2 3 1136 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 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Reserved for future framing type definitions |A|S| 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 1141 The Attribute Value field is a 32-bit mask, with two bits defined. 1142 If bit A is set, asynchronous framing is supported. If bit S is 1143 set, synchronous framing is supported. 1144 1145 A peer MUST NOT request an incoming or outgoing call with a 1146 Framing Type AVP specifying a value not advertised in the Framing 1147 Capabilities AVP it received during control connection 1148 establishment. Attempts to do so will result in the call being 1149 rejected. 1150 1151 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1152 this AVP MUST be set to 1. The Length (before hiding) is 10. 1153 1154 Bearer Capabilities (SCCRP, SCCRQ) 1155 1156 The Bearer Capabilities AVP, Attribute Type 4, provides the peer 1157 with an indication of the bearer device types supported by the 1158 hardware interfaces of the sender for outgoing calls. 1159 1160 The Attribute Value field for this AVP has the following format: 1161 1162 0 1 2 3 1163 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 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | Reserved for future bearer type definitions |A|D| 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 1168 This is a 32-bit mask, with two bits defined. If bit A is set, 1169 analog access is supported. If bit D is set, digital access is 1170 supported. 1171 1172 1173 1174 1175 1176 1177 1178Townsley, et al. Standards Track [Page 21] 1179 1180RFC 2661 L2TP August 1999 1181 1182 1183 An LNS should not request an outgoing call specifying a value in 1184 the Bearer Type AVP for a device type not advertised in the Bearer 1185 Capabilities AVP it received from the LAC during control 1186 connection establishment. Attempts to do so will result in the 1187 call being rejected. 1188 1189 This AVP MUST be present if the sender can place outgoing calls 1190 when requested. 1191 1192 Note that an LNS that cannot act as an LAC as well will not 1193 support hardware devices for handling incoming and outgoing calls 1194 and should therefore set the A and D bits of this AVP to 0, or 1195 should not send the AVP at all. An LNS that can also act as an LAC 1196 and place outgoing calls should set A or D as appropriate. 1197 Presence of this message is not a guarantee that a given outgoing 1198 call will be placed by the sender if requested, just that the 1199 physical capability exists. 1200 1201 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1202 this AVP MUST be set to 1. The Length (before hiding) is 10. 1203 1204 Tie Breaker (SCCRQ) 1205 1206 The Tie Breaker AVP, Attribute Type 5, indicates that the sender 1207 wishes a single tunnel to exist between the given LAC-LNS pair. 1208 1209 The Attribute Value field for this AVP has the following format: 1210 1211 0 1 2 3 1212 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 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | Tie Break Value... 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 ...(64 bits) | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 1219 The Tie Breaker Value is an 8 octet value that is used to choose a 1220 single tunnel where both LAC and LNS request a tunnel 1221 concurrently. The recipient of a SCCRQ must check to see if a 1222 SCCRQ has been sent to the peer, and if so, must compare its Tie 1223 Breaker value with the received one. The lower value "wins", and 1224 the "loser" MUST silently discard its tunnel. In the case where a 1225 tie breaker is present on both sides, and the value is equal, both 1226 sides MUST discard their tunnels. 1227 1228 1229 1230 1231 1232 1233 1234Townsley, et al. Standards Track [Page 22] 1235 1236RFC 2661 L2TP August 1999 1237 1238 1239 If a tie breaker is received, and an outstanding SCCRQ had no tie 1240 breaker value, the initiator which included the Tie Breaker AVP 1241 "wins". If neither side issues a tie breaker, then two separate 1242 tunnels are opened. 1243 1244 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1245 this AVP MUST be set to 0. The Length of this AVP is 14. 1246 1247 Firmware Revision (SCCRP, SCCRQ) 1248 1249 The Firmware Revision AVP, Attribute Type 6, indicates the 1250 firmware revision of the issuing device. 1251 1252 The Attribute Value field for this AVP has the following format: 1253 1254 0 1 1255 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | Firmware Revision | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 1260 The Firmware Revision is a 2 octet unsigned integer encoded in a 1261 vendor specific format. 1262 1263 For devices which do not have a firmware revision (general purpose 1264 computers running L2TP software modules, for instance), the 1265 revision of the L2TP software module may be reported instead. 1266 1267 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1268 this AVP MUST be set to 0. The Length (before hiding) is 8. 1269 1270 Host Name (SCCRP, SCCRQ) 1271 1272 The Host Name AVP, Attribute Type 7, indicates the name of the 1273 issuing LAC or LNS. 1274 1275 The Attribute Value field for this AVP has the following format: 1276 1277 0 1 2 3 1278 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | Host Name ... (arbitrary number of octets) 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 1283 The Host Name is of arbitrary length, but MUST be at least 1 1284 octet. 1285 1286 1287 1288 1289 1290Townsley, et al. Standards Track [Page 23] 1291 1292RFC 2661 L2TP August 1999 1293 1294 1295 This name should be as broadly unique as possible; for hosts 1296 participating in DNS [RFC1034], a hostname with fully qualified 1297 domain would be appropriate. 1298 1299 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1300 this AVP MUST be set to 1. The Length of this AVP is 6 plus the 1301 length of the Host Name. 1302 1303 Vendor Name (SCCRP, SCCRQ) 1304 1305 The Vendor Name AVP, Attribute Type 8, contains a vendor specific 1306 (possibly human readable) string describing the type of LAC or LNS 1307 being used. 1308 1309 The Attribute Value field for this AVP has the following format: 1310 1311 0 1 2 3 1312 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 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | Vendor Name ...(arbitrary number of octets) 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 1317 The Vendor Name is the indicated number of octets representing the 1318 vendor string. Human readable text for this AVP MUST be provided 1319 in the UTF-8 charset using the Default Language [RFC2277]. 1320 1321 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1322 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1323 is 6 plus the length of the Vendor Name. 1324 1325 Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN) 1326 1327 The Assigned Tunnel ID AVP, Attribute Type 9, encodes the ID being 1328 assigned to this tunnel by the sender. 1329 1330 The Attribute Value field for this AVP has the following format: 1331 1332 0 1 1333 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Assigned Tunnel ID | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 1338 The Assigned Tunnel ID is a 2 octet non-zero unsigned integer. 1339 1340 The Assigned Tunnel ID AVP establishes a value used to multiplex 1341 and demultiplex multiple tunnels between the LNS and LAC. The L2TP 1342 peer MUST place this value in the Tunnel ID header field of all 1343 1344 1345 1346Townsley, et al. Standards Track [Page 24] 1347 1348RFC 2661 L2TP August 1999 1349 1350 1351 control and data messages that it subsequently transmits over the 1352 associated tunnel. Before the Assigned Tunnel ID AVP is received 1353 from a peer, messages MUST be sent to that peer with a Tunnel ID 1354 value of 0 in the header of all control messages. 1355 1356 In the StopCCN control message, the Assigned Tunnel ID AVP MUST be 1357 the same as the Assigned Tunnel ID AVP first sent to the receiving 1358 peer, permitting the peer to identify the appropriate tunnel even 1359 if a StopCCN is sent before an Assigned Tunnel ID AVP is received. 1360 1361 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1362 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1363 is 8. 1364 1365 Receive Window Size (SCCRQ, SCCRP) 1366 1367 The Receive Window Size AVP, Attribute Type 10, specifies the 1368 receive window size being offered to the remote peer. 1369 1370 The Attribute Value field for this AVP has the following format: 1371 1372 0 1 1373 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | Window Size | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 1378 The Window Size is a 2 octet unsigned integer. 1379 1380 If absent, the peer must assume a Window Size of 4 for its 1381 transmit window. The remote peer may send the specified number of 1382 control messages before it must wait for an acknowledgment. 1383 1384 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1385 this AVP MUST be set to 1. The Length of this AVP is 8. 1386 1387 Challenge (SCCRP, SCCRQ) 1388 1389 The Challenge AVP, Attribute Type 11, indicates that the issuing 1390 peer wishes to authenticate the tunnel endpoints using a CHAP- 1391 style authentication mechanism. 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402Townsley, et al. Standards Track [Page 25] 1403 1404RFC 2661 L2TP August 1999 1405 1406 1407 The Attribute Value field for this AVP has the following format: 1408 1409 0 1 2 3 1410 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 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | Challenge ... (arbitrary number of octets) 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 1415 The Challenge is one or more octets of random data. 1416 1417 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1418 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1419 is 6 plus the length of the Challenge. 1420 1421 Challenge Response (SCCCN, SCCRP) 1422 1423 The Response AVP, Attribute Type 13, provides a response to a 1424 challenge received. 1425 1426 The Attribute Value field for this AVP has the following format: 1427 1428 0 1 2 3 1429 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 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | Response ... 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 ... (16 octets) | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 1440 The Response is a 16 octet value reflecting the CHAP-style 1441 [RFC1994] response to the challenge. 1442 1443 This AVP MUST be present in an SCCRP or SCCCN if a challenge was 1444 received in the preceding SCCRQ or SCCRP. For purposes of the ID 1445 value in the CHAP response calculation, the value of the Message 1446 Type AVP for this message is used (e.g. 2 for an SCCRP, and 3 for 1447 an SCCCN). 1448 1449 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1450 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1451 is 22. 1452 1453 1454 1455 1456 1457 1458Townsley, et al. Standards Track [Page 26] 1459 1460RFC 2661 L2TP August 1999 1461 1462 14634.4.4 Call Management AVPs 1464 1465 Q.931 Cause Code (CDN) 1466 1467 The Q.931 Cause Code AVP, Attribute Type 12, is used to give 1468 additional information in case of unsolicited call disconnection. 1469 1470 The Attribute Value field for this AVP has the following format: 1471 1472 0 1 2 3 1473 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 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 | Cause Code | Cause Msg | Advisory Msg... 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 1478 Cause Code is the returned Q.931 Cause code, and Cause Msg is the 1479 returned Q.931 message code (e.g., DISCONNECT) associated with the 1480 Cause Code. Both values are returned in their native ITU 1481 encodings [DSS1]. An additional ASCII text Advisory Message may 1482 also be included (presence indicated by the AVP Length) to further 1483 explain the reason for disconnecting. 1484 1485 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1486 this AVP MUST be set to 1. The Length of this AVP is 9, plus the 1487 size of the Advisory Message. 1488 1489 Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ) 1490 1491 The Assigned Session ID AVP, Attribute Type 14, encodes the ID 1492 being assigned to this session by the sender. 1493 1494 The Attribute Value field for this AVP has the following format: 1495 1496 0 1 1497 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | Assigned Session ID | 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 1502 The Assigned Session ID is a 2 octet non-zero unsigned integer. 1503 1504 The Assigned Session ID AVP is establishes a value used to 1505 multiplex and demultiplex data sent over a tunnel between the LNS 1506 and LAC. The L2TP peer MUST place this value in the Session ID 1507 header field of all control and data messages that it subsequently 1508 transmits over the tunnel that belong to this session. Before the 1509 1510 1511 1512 1513 1514Townsley, et al. Standards Track [Page 27] 1515 1516RFC 2661 L2TP August 1999 1517 1518 1519 Assigned Session ID AVP is received from a peer, messages MUST be 1520 sent to that peer with a Session ID of 0 in the header of all 1521 control messages. 1522 1523 In the CDN control message, the same Assigned Session ID AVP first 1524 sent to the receiving peer is used, permitting the peer to 1525 identify the appropriate tunnel even if CDN is sent before an 1526 Assigned Session ID is received. 1527 1528 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1529 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1530 is 8. 1531 1532 Call Serial Number (ICRQ, OCRQ) 1533 1534 The Call Serial Number AVP, Attribute Type 15, encodes an 1535 identifier assigned by the LAC or LNS to this call. 1536 1537 The Attribute Value field for this AVP has the following format: 1538 1539 0 1 2 3 1540 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 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 | Call Serial Number | 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 1545 The Call Serial Number is a 32 bit value. 1546 1547 The Call Serial Number is intended to be an easy reference for 1548 administrators on both ends of a tunnel to use when investigating 1549 call failure problems. Call Serial Numbers should be set to 1550 progressively increasing values, which are likely to be unique for 1551 a significant period of time across all interconnected LNSs and 1552 LACs. 1553 1554 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1555 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1556 is 10. 1557 1558 Minimum BPS (OCRQ) 1559 1560 The Minimum BPS AVP, Attribute Type 16, encodes the lowest 1561 acceptable line speed for this call. 1562 1563 1564 1565 1566 1567 1568 1569 1570Townsley, et al. Standards Track [Page 28] 1571 1572RFC 2661 L2TP August 1999 1573 1574 1575 The Attribute Value field for this AVP has the following format: 1576 1577 0 1 2 3 1578 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 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Minimum BPS | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 1583 The Minimum BPS is a 32 bit value indicates the speed in bits per 1584 second. 1585 1586 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1587 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1588 is 10. 1589 1590 Maximum BPS (OCRQ) 1591 1592 The Maximum BPS AVP, Attribute Type 17, encodes the highest 1593 acceptable line speed for this call. 1594 1595 The Attribute Value field for this AVP has the following format: 1596 1597 0 1 2 3 1598 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 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | Maximum BPS | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 1603 The Maximum BPS is a 32 bit value indicates the speed in bits per 1604 second. 1605 1606 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1607 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1608 is 10. 1609 1610 Bearer Type (ICRQ, OCRQ) 1611 1612 The Bearer Type AVP, Attribute Type 18, encodes the bearer type 1613 for the incoming or outgoing call. 1614 1615 The Attribute Value field for this AVP has the following format: 1616 1617 0 1 2 3 1618 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 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | Reserved for future Bearer Types |A|D| 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 1623 1624 1625 1626Townsley, et al. Standards Track [Page 29] 1627 1628RFC 2661 L2TP August 1999 1629 1630 1631 The Bearer Type is a 32-bit bit mask, which indicates the bearer 1632 capability of the call (ICRQ) or required for the call (OCRQ). If 1633 set, bit A indicates that the call refers to an analog channel. If 1634 set, bit D indicates that the call refers to a digital channel. 1635 Both may be set, indicating that the call was either 1636 indistinguishable, or can be placed on either type of channel. 1637 1638 Bits in the Value field of this AVP MUST only be set by the LNS 1639 for an OCRQ if it was set in the Bearer Capabilities AVP received 1640 from the LAC during control connection establishment. 1641 1642 It is valid to set neither the A nor D bits in an ICRQ. Such a 1643 setting may indicate that the call was not received over a 1644 physical link (e.g if the LAC and PPP are located in the same 1645 subsystem). 1646 1647 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1648 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1649 is 10. 1650 1651 Framing Type (ICCN, OCCN, OCRQ) 1652 1653 The Framing Type AVP, Attribute Type 19, encodes the framing type 1654 for the incoming or outgoing call. 1655 1656 The Attribute Value field for this AVP has the following format: 1657 1658 0 1 2 3 1659 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 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 | Reserved for future Framing Types |A|S| 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 1664 The Framing Type is a 32-bit mask, which indicates the type of PPP 1665 framing requested for an OCRQ, or the type of PPP framing 1666 negotiated for an OCCN or ICCN. The framing type MAY be used as an 1667 indication to PPP on the LNS as to what link options to use for 1668 LCP negotiation [RFC1662]. 1669 1670 Bit A indicates asynchronous framing. Bit S indicates synchronous 1671 framing. For an OCRQ, both may be set, indicating that either type 1672 of framing may be used. 1673 1674 Bits in the Value field of this AVP MUST only be set by the LNS 1675 for an OCRQ if it was set in the Framing Capabilities AVP received 1676 from the LAC during control connection establishment. 1677 1678 1679 1680 1681 1682Townsley, et al. Standards Track [Page 30] 1683 1684RFC 2661 L2TP August 1999 1685 1686 1687 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1688 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1689 is 10. 1690 1691 Called Number (ICRQ, OCRQ) 1692 1693 The Called Number AVP, Attribute Type 21, encodes the telephone 1694 number to be called for an OCRQ, and the Called number for an 1695 ICRQ. 1696 1697 The Attribute Value field for this AVP has the following format: 1698 1699 0 1 2 3 1700 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 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | Called Number... (arbitrary number of octets) | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 1705 The Called Number is an ASCII string. Contact between the 1706 administrator of the LAC and the LNS may be necessary to 1707 coordinate interpretation of the value needed in this AVP. 1708 1709 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1710 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1711 is 6 plus the length of the Called Number. 1712 1713 Calling Number (ICRQ) 1714 1715 The Calling Number AVP, Attribute Type 22, encodes the originating 1716 number for the incoming call. 1717 1718 The Attribute Value field for this AVP has the following format: 1719 1720 0 1 2 3 1721 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 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 | Calling Number... (arbitrary number of octets) | 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 1726 Calling Number is an ASCII string. Contact between the 1727 administrator of the LAC and the LNS may be necessary to 1728 coordinate interpretation of the value in this AVP. 1729 1730 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1731 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1732 is 6 plus the length of the Calling Number. 1733 1734 1735 1736 1737 1738Townsley, et al. Standards Track [Page 31] 1739 1740RFC 2661 L2TP August 1999 1741 1742 1743 Sub-Address (ICRQ, OCRQ) 1744 1745 The Sub-Address AVP, Attribute Type 23, encodes additional dialing 1746 information. 1747 1748 The Attribute Value field for this AVP has the following format: 1749 1750 0 1 2 3 1751 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 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 | Sub-Address ... (arbitrary number of octets) | 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 1756 The Sub-Address is an ASCII string. Contact between the 1757 administrator of the LAC and the LNS may be necessary to 1758 coordinate interpretation of the value in this AVP. 1759 1760 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1761 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1762 is 6 plus the length of the Sub-Address. 1763 1764 (Tx) Connect Speed (ICCN, OCCN) 1765 1766 The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes the 1767 speed of the facility chosen for the connection attempt. 1768 1769 The Attribute Value field for this AVP has the following format: 1770 1771 0 1 2 3 1772 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 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 | BPS | 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 1777 The (Tx) Connect Speed BPS is a 4 octet value indicating the speed 1778 in bits per second. 1779 1780 When the optional Rx Connect Speed AVP is present, the value in 1781 this AVP represents the transmit connect speed, from the 1782 perspective of the LAC (e.g. data flowing from the LAC to the 1783 remote system). When the optional Rx Connect Speed AVP is NOT 1784 present, the connection speed between the remote system and LAC is 1785 assumed to be symmetric and is represented by the single value in 1786 this AVP. 1787 1788 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1789 this AVP MUST be set to 1. The Length (before hiding) of this AVP 1790 is 10. 1791 1792 1793 1794Townsley, et al. Standards Track [Page 32] 1795 1796RFC 2661 L2TP August 1999 1797 1798 1799 Rx Connect Speed (ICCN, OCCN) 1800 1801 The Rx Connect Speed AVP, Attribute Type 38, represents the speed 1802 of the connection from the perspective of the LAC (e.g. data 1803 flowing from the remote system to the LAC). 1804 1805 The Attribute Value field for this AVP has the following format: 1806 1807 0 1 2 3 1808 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 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 | BPS (H) | BPS (L) | 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 1813 BPS is a 4 octet value indicating the speed in bits per second. 1814 1815 Presence of this AVP implies that the connection speed may be 1816 asymmetric with respect to the transmit connect speed given in the 1817 (Tx) Connect Speed AVP. 1818 1819 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for 1820 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1821 is 10. 1822 1823 Physical Channel ID (ICRQ, OCRP) 1824 1825 The Physical Channel ID AVP, Attribute Type 25, encodes the vendor 1826 specific physical channel number used for a call. 1827 1828 The Attribute Value field for this AVP has the following format: 1829 1830 0 1 2 3 1831 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 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 | Physical Channel ID | 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 1836 Physical Channel ID is a 4 octet value intended to be used for 1837 logging purposes only. 1838 1839 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1840 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1841 is 10. 1842 1843 1844 1845 1846 1847 1848 1849 1850Townsley, et al. Standards Track [Page 33] 1851 1852RFC 2661 L2TP August 1999 1853 1854 1855 Private Group ID (ICCN) 1856 1857 The Private Group ID AVP, Attribute Type 37, is used by the LAC to 1858 indicate that this call is to be associated with a particular 1859 customer group. 1860 1861 The Attribute Value field for this AVP has the following format: 1862 1863 0 1 2 3 1864 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 1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1866 | Private Group ID ... (arbitrary number of octets) | 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 1869 The Private Group ID is a string of octets of arbitrary length. 1870 1871 The LNS MAY treat the PPP session as well as network traffic 1872 through this session in a special manner determined by the peer. 1873 For example, if the LNS is individually connected to several 1874 private networks using unregistered addresses, this AVP may be 1875 included by the LAC to indicate that a given call should be 1876 associated with one of the private networks. 1877 1878 The Private Group ID is a string corresponding to a table in the 1879 LNS that defines the particular characteristics of the selected 1880 group. A LAC MAY determine the Private Group ID from a RADIUS 1881 response, local configuration, or some other source. 1882 1883 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for 1884 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1885 is 6 plus the length of the Private Group ID. 1886 1887 Sequencing Required (ICCN, OCCN) 1888 1889 The Sequencing Required AVP, Attribute Type 39, indicates to the 1890 LNS that Sequence Numbers MUST always be present on the data 1891 channel. 1892 1893 This AVP has no Attribute Value field. 1894 1895 This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for 1896 this AVP MUST be set to 1. The Length of this AVP is 6. 1897 18984.4.5 Proxy LCP and Authentication AVPs 1899 1900 The LAC may have answered the call and negotiated LCP with the 1901 remote system, perhaps in order to establish the system's apparent 1902 identity. In this case, these AVPs may be included to indicate the 1903 1904 1905 1906Townsley, et al. Standards Track [Page 34] 1907 1908RFC 2661 L2TP August 1999 1909 1910 1911 link properties the remote system initially requested, properties 1912 the remote system and LAC ultimately negotiated, as well as PPP 1913 authentication information sent and received by the LAC. This 1914 information may be used to initiate the PPP LCP and authentication 1915 systems on the LNS, allowing PPP to continue without renegotiation 1916 of LCP. Note that the LNS policy may be to enter an additional 1917 round of LCP negotiation and/or authentication if the LAC is not 1918 trusted. 1919 1920 Initial Received LCP CONFREQ (ICCN) 1921 1922 In the Initial Received LCP CONFREQ AVP, Attribute Type 26, 1923 provides the LNS with the Initial CONFREQ received by the LAC from 1924 the PPP Peer. 1925 1926 The Attribute Value field for this AVP has the following format: 1927 1928 0 1 2 3 1929 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 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 | LCP CONFREQ... (arbitrary number of octets) | 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 1934 LCP CONFREQ is a copy of the body of the initial CONFREQ received, 1935 starting at the first option within the body of the LCP message. 1936 1937 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1938 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1939 is 6 plus the length of the CONFREQ. 1940 1941 Last Sent LCP CONFREQ (ICCN) 1942 1943 In the Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the 1944 LNS with the Last CONFREQ sent by the LAC to the PPP Peer. 1945 1946 The Attribute Value field for this AVP has the following format: 1947 1948 0 1 2 3 1949 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 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 | LCP CONFREQ... (arbitrary number of octets) | 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 1954 The LCP CONFREQ is a copy of the body of the final CONFREQ sent to 1955 the client to complete LCP negotiation, starting at the first 1956 option within the body of the LCP message. 1957 1958 1959 1960 1961 1962Townsley, et al. Standards Track [Page 35] 1963 1964RFC 2661 L2TP August 1999 1965 1966 1967 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1968 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1969 is 6 plus the length of the CONFREQ. 1970 1971 Last Received LCP CONFREQ (ICCN) 1972 1973 The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the 1974 LNS with the Last CONFREQ received by the LAC from the PPP Peer. 1975 1976 The Attribute Value field for this AVP has the following format: 1977 1978 0 1 2 3 1979 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 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | LCP CONFREQ... (arbitrary number of octets) | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 1984 The LCP CONFREQ is a copy of the body of the final CONFREQ 1985 received from the client to complete LCP negotiation, starting at 1986 the first option within the body of the LCP message. 1987 1988 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 1989 this AVP MUST be set to 0. The Length (before hiding) of this AVP 1990 is 6 plus the length of the CONFREQ. 1991 1992 Proxy Authen Type (ICCN) 1993 1994 The Proxy Authen Type AVP, Attribute Type 29, determines if proxy 1995 authentication should be used. 1996 1997 The Attribute Value field for this AVP has the following format: 1998 1999 0 1 2000 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 | Authen Type | 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 2005 Authen Type is a 2 octet unsigned integer, holding: 2006 2007 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 2008 this AVP MUST be set to 0. The Length (before hiding) of this AVP 2009 is 8. 2010 2011 2012 2013 2014 2015 2016 2017 2018Townsley, et al. Standards Track [Page 36] 2019 2020RFC 2661 L2TP August 1999 2021 2022 2023 Defined Authen Type values are: 2024 0 - Reserved 2025 1 - Textual username/password exchange 2026 2 - PPP CHAP 2027 3 - PPP PAP 2028 4 - No Authentication 2029 5 - Microsoft CHAP Version 1 (MSCHAPv1) 2030 2031 This AVP MUST be present if proxy authentication is to be 2032 utilized. If it is not present, then it is assumed that this 2033 peer cannot perform proxy authentication, requiring 2034 a restart of the authentication phase at the LNS if the client 2035 has already entered this phase with the 2036 LAC (which may be determined by the Proxy LCP AVP if present). 2037 2038 Associated AVPs for each type of authentication follow. 2039 2040 Proxy Authen Name (ICCN) 2041 2042 The Proxy Authen Name AVP, Attribute Type 30, specifies the name 2043 of the authenticating client when using proxy authentication. 2044 2045 The Attribute Value field for this AVP has the following format: 2046 2047 0 1 2 3 2048 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 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2050 | Authen Name... (arbitrary number of octets) | 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2052 2053 Authen Name is a string of octets of arbitrary length. It 2054 contains the name specified in the client's authentication 2055 response. 2056 2057 This AVP MUST be present in messages containing a Proxy Authen 2058 Type AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable 2059 to employ AVP hiding for obscuring the cleartext name. 2060 2061 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 2062 this AVP MUST be set to 0. The Length (before hiding) is 6 plus 2063 the length of the cleartext name. 2064 2065 Proxy Authen Challenge (ICCN) 2066 2067 The Proxy Authen Challenge AVP, Attribute Type 31, specifies the 2068 challenge sent by the LAC to the PPP Peer, when using proxy 2069 authentication. 2070 2071 2072 2073 2074Townsley, et al. Standards Track [Page 37] 2075 2076RFC 2661 L2TP August 1999 2077 2078 2079 The Attribute Value field for this AVP has the following format: 2080 2081 0 1 2 3 2082 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 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 | Challenge... (arbitrary number of octets) | 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2086 2087 The Challenge is a string of one or more octets. 2088 2089 This AVP MUST be present for Proxy Authen Types 2 and 5. The 2090 Challenge field contains the CHAP challenge presented to the 2091 client by the LAC. 2092 2093 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 2094 this AVP MUST be set to 0. The Length (before hiding) of this AVP 2095 is 6, plus the length of the Challenge. 2096 2097 Proxy Authen ID (ICCN) 2098 2099 The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value 2100 of the PPP Authentication that was started between the LAC and the 2101 PPP Peer, when proxy authentication is being used. 2102 2103 The Attribute Value field for this AVP has the following format: 2104 2105 0 1 2106 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 | Reserved | ID | 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2110 2111 ID is a 2 octet unsigned integer, the most significant octet MUST 2112 be 0. 2113 2114 The Proxy Authen ID AVP MUST be present for Proxy authen types 2, 2115 3 and 5. For 2 and 5, the ID field contains the byte ID value 2116 presented to the client by the LAC in its Challenge. For 3, it is 2117 the Identifier value of the Authenticate-Request. 2118 2119 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 2120 this AVP MUST be set to 0. 2121 2122 Proxy Authen Response (ICCN) 2123 2124 The Proxy Authen Response AVP, Attribute Type 33, specifies the 2125 PPP Authentication response received by the LAC from the PPP Peer, 2126 when proxy authentication is used. 2127 2128 2129 2130Townsley, et al. Standards Track [Page 38] 2131 2132RFC 2661 L2TP August 1999 2133 2134 2135 The Attribute Value field for this AVP has the following format: 2136 2137 0 1 2 3 2138 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 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | Response... (arbitrary number of octets) | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 2143 The Response is a string of octets. 2144 2145 This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The 2146 Response field contains the client's response to the challenge. 2147 For Proxy authen types 2 and 5, this field contains the response 2148 value received by the LAC. For types 1 or 3, it contains the clear 2149 text password received from the client by the LAC. In the case of 2150 cleartext passwords, AVP hiding is recommended. 2151 2152 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 2153 this AVP MUST be set to 0. The Length (before hiding) of this AVP 2154 is 6 plus the length of the Response. 2155 21564.4.6 Call Status AVPs 2157 2158 Call Errors (WEN) 2159 2160 The Call Errors AVP, Attribute Type 34, is used by the LAC to send 2161 error information to the LNS. 2162 2163 The Attribute Value field for this AVP has the following format: 2164 2165 0 1 2 3 2166 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 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | Reserved | CRC Errors (H) | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | CRC Errors (L) | Framing Errors (H) | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 | Framing Errors (L) | Hardware Overruns (H) | 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | Hardware Overruns (L) | Buffer Overruns (H) | 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 | Buffer Overruns (L) | Time-out Errors (H) | 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 | Time-out Errors (L) | Alignment Errors (H) | 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 | Alignment Errors (L) | 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 2183 2184 2185 2186Townsley, et al. Standards Track [Page 39] 2187 2188RFC 2661 L2TP August 1999 2189 2190 2191 The following fields are defined: 2192 2193 Reserved - Not used, MUST be 0 2194 CRC Errors - Number of PPP frames received with CRC errors 2195 since call was established 2196 Framing Errors - Number of improperly framed PPP packets 2197 received 2198 Hardware Overruns - Number of receive buffer over-runs since 2199 call was established 2200 Buffer Overruns - Number of buffer over-runs detected since 2201 call was established 2202 Time-out Errors - Number of time-outs since call was 2203 established 2204 Alignment Errors - Number of alignment errors since call was 2205 established 2206 2207 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for 2208 this AVP MUST be set to 1. The Length (before hiding) of this AVP 2209 is 32. 2210 2211 ACCM (SLI) 2212 2213 The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC 2214 of the ACCM negotiated with the PPP Peer by the LNS. 2215 2216 The Attribute Value field for this AVP has the following format: 2217 2218 0 1 2 3 2219 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2221 | Reserved | Send ACCM (H) | 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 | Send ACCM (L) | Receive ACCM (H) | 2224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2225 | Receive ACCM (L) | 2226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2227 2228 Send ACCM and Receive ACCM are each 4 octet values preceded by a 2 2229 octet reserved quantity. The send ACCM value should be used by the 2230 LAC to process packets it sends on the connection. The receive 2231 ACCM value should be used by the LAC to process incoming packets 2232 on the connection. The default values used by the LAC for both 2233 these fields are 0xFFFFFFFF. The LAC should honor these fields 2234 unless it has specific configuration information to indicate that 2235 the requested mask must be modified to permit operation. 2236 2237 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for 2238 this AVP MUST be set to 1. The Length of this AVP is 16. 2239 2240 2241 2242Townsley, et al. Standards Track [Page 40] 2243 2244RFC 2661 L2TP August 1999 2245 2246 22475.0 Protocol Operation 2248 2249 The necessary setup for tunneling a PPP session with L2TP consists of 2250 two steps, (1) establishing the Control Connection for a Tunnel, and 2251 (2) establishing a Session as triggered by an incoming or outgoing 2252 call request. The Tunnel and corresponding Control Connection MUST be 2253 established before an incoming or outgoing call is initiated. An L2TP 2254 Session MUST be established before L2TP can begin to tunnel PPP 2255 frames. Multiple Sessions may exist across a single Tunnel and 2256 multiple Tunnels may exist between the same LAC and LNS. 2257 2258 +-----+ +-----+ 2259 | |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~| | 2260 | LAC | | LNS | 2261 | #######Control Connection######## | 2262 [Remote] | | | | 2263 [System]------Call----------*============L2TP Session=============* | 2264 PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | 2265 | | | | 2266 [Remote] | | | | 2267 [System]------Call----------*============L2TP Session=============* | 2268 PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | 2269 | | | | 2270 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | 2271 +-----+ +-----+ 2272 2273 Figure 5.1 Tunneling PPP 2274 22755.1 Control Connection Establishment 2276 2277 The Control Connection is the initial connection that must be 2278 achieved between an LAC and LNS before sessions may be brought up. 2279 Establishment of the control connection includes securing the 2280 identity of the peer, as well as identifying the peer's L2TP version, 2281 framing, and bearer capabilities, etc. 2282 2283 A three message exchange is utilized to setup the control connection. 2284 Following is a typical message exchange: 2285 2286 LAC or LNS LAC or LNS 2287 ---------- ---------- 2288 SCCRQ -> 2289 <- SCCRP 2290 SCCCN -> 2291 <- ZLB ACK 2292 2293 The ZLB ACK is sent if there are no further messages waiting in queue 2294 for that peer. 2295 2296 2297 2298Townsley, et al. Standards Track [Page 41] 2299 2300RFC 2661 L2TP August 1999 2301 2302 23035.1.1 Tunnel Authentication 2304 2305 L2TP incorporates a simple, optional, CHAP-like [RFC1994] tunnel 2306 authentication system during control connection establishment. If an 2307 LAC or LNS wishes to authenticate the identity of the peer it is 2308 contacting or being contacted by, a Challenge AVP is included in the 2309 SCCRQ or SCCRP message. If a Challenge AVP is received in an SCCRQ or 2310 SCCRP, a Challenge Response AVP MUST be sent in the following SCCRP 2311 or SCCCN, respectively. If the expected response and response 2312 received from a peer does not match, establishment of the tunnel MUST 2313 be disallowed. 2314 2315 To participate in tunnel authentication, a single shared secret MUST 2316 exist between the LAC and LNS. This is the same shared secret used 2317 for AVP hiding (see Section 4.3). See Section 4.4.3 for details on 2318 construction of the Challenge and Response AVPs. 2319 23205.2 Session Establishment 2321 2322 After successful control connection establishment, individual 2323 sessions may be created. Each session corresponds to single PPP 2324 stream between the LAC and LNS. Unlike control connection 2325 establishment, session establishment is directional with respect to 2326 the LAC and LNS. The LAC requests the LNS to accept a session for an 2327 incoming call, and the LNS requests the LAC to accept a session for 2328 placing an outgoing call. 2329 23305.2.1 Incoming Call Establishment 2331 2332 A three message exchange is employed to setup the session. Following 2333 is a typical sequence of events: 2334 2335 LAC LNS 2336 --- --- 2337 (Call 2338 Detected) 2339 2340 ICRQ -> 2341 <- ICRP 2342 ICCN -> 2343 <- ZLB ACK 2344 2345 The ZLB ACK is sent if there are no further messages waiting in queue 2346 for that peer. 2347 2348 2349 2350 2351 2352 2353 2354Townsley, et al. Standards Track [Page 42] 2355 2356RFC 2661 L2TP August 1999 2357 2358 23595.2.2 Outgoing Call Establishment 2360 2361 A three message exchange is employed to setup the session. Following 2362 is a typical sequence of events: 2363 2364 LAC LNS 2365 --- --- 2366 <- OCRQ 2367 OCRP -> 2368 2369 (Perform 2370 Call 2371 Operation) 2372 2373 OCCN -> 2374 <- ZLB ACK 2375 2376 The ZLB ACK is sent if there are no further messages waiting in queue 2377 for that peer. 2378 23795.3 Forwarding PPP Frames 2380 2381 Once tunnel establishment is complete, PPP frames from the remote 2382 system are received at the LAC, stripped of CRC, link framing, and 2383 transparency bytes, encapsulated in L2TP, and forwarded over the 2384 appropriate tunnel. The LNS receives the L2TP packet, and processes 2385 the encapsulated PPP frame as if it were received on a local PPP 2386 interface. 2387 2388 The sender of a message associated with a particular session and 2389 tunnel places the Session ID and Tunnel ID (specified by its peer) in 2390 the Session ID and Tunnel ID header for all outgoing messages. In 2391 this manner, PPP frames are multiplexed and demultiplexed over a 2392 single tunnel between a given LNS-LAC pair. Multiple tunnels may 2393 exist between a given LNS-LAC pair, and multiple sessions may exist 2394 within a tunnel. 2395 2396 The value of 0 for Session ID and Tunnel ID is special and MUST NOT 2397 be used as an Assigned Session ID or Assigned Tunnel ID. For the 2398 cases where a Session ID has not yet been assigned by the peer (i.e., 2399 during establishment of a new session or tunnel), the Session ID 2400 field MUST be sent as 0, and the Assigned Session ID AVP within the 2401 message MUST be used to identify the session. Similarly, for cases 2402 where the Tunnel ID has not yet been assigned from the peer, the 2403 Tunnel ID MUST be sent as 0 and Assigned Tunnel ID AVP used to 2404 identify the tunnel. 2405 2406 2407 2408 2409 2410Townsley, et al. Standards Track [Page 43] 2411 2412RFC 2661 L2TP August 1999 2413 2414 24155.4 Using Sequence Numbers on the Data Channel 2416 2417 Sequence numbers are defined in the L2TP header for control messages 2418 and optionally for data messages (see Section 3.1). These are used to 2419 provide a reliable control message transport (see Section 5.8) and 2420 optional data message sequencing. Each peer maintains separate 2421 sequence numbers for the control connection and each individual data 2422 session within a tunnel. 2423 2424 Unlike the L2TP control channel, the L2TP data channel does not use 2425 sequence numbers to retransmit lost data messages. Rather, data 2426 messages may use sequence numbers to detect lost packets and/or 2427 restore the original sequence of packets that may have been reordered 2428 during transport. The LAC may request that sequence numbers be 2429 present in data messages via the Sequencing Required AVP (see Section 2430 4.4.6). If this AVP is present during session setup, sequence numbers 2431 MUST be present at all times. If this AVP is not present, sequencing 2432 presence is under control of the LNS. The LNS controls enabling and 2433 disabling of sequence numbers by sending a data message with or 2434 without sequence numbers present at any time during the life of a 2435 session. Thus, if the LAC receives a data message without sequence 2436 numbers present, it MUST stop sending sequence numbers in future data 2437 messages. If the LAC receives a data message with sequence numbers 2438 present, it MUST begin sending sequence numbers in future outgoing 2439 data messages. If the LNS enables sequencing after disabling it 2440 earlier in the session, the sequence number state picks up where it 2441 left off before. 2442 2443 The LNS may initiate disabling of sequencing at any time during the 2444 session (including the first data message sent). It is recommended 2445 that for connections where reordering or packet loss may occur, 2446 sequence numbers always be enabled during the initial negotiation 2447 stages of PPP and disabled only when and if the risk is considered 2448 acceptable. For example, if the PPP session being tunneled is not 2449 utilizing any stateful compression or encryption protocols and is 2450 only carrying IP (as determined by the PPP NCPs that are 2451 established), then the LNS might decide to disable sequencing as IP 2452 is tolerant to datagram loss and reordering. 2453 24545.5 Keepalive (Hello) 2455 2456 A keepalive mechanism is employed by L2TP in order to differentiate 2457 tunnel outages from extended periods of no control or data activity 2458 on a tunnel. This is accomplished by injecting Hello control messages 2459 (see Section 6.5) after a specified period of time has elapsed since 2460 the last data or control message was received on a tunnel. As for any 2461 other control message, if the Hello message is not reliably delivered 2462 then the tunnel is declared down and is reset. The transport reset 2463 2464 2465 2466Townsley, et al. Standards Track [Page 44] 2467 2468RFC 2661 L2TP August 1999 2469 2470 2471 mechanism along with the injection of Hello messages ensures that a 2472 connectivity failure between the LNS and the LAC will be detected at 2473 both ends of a tunnel. 2474 24755.6 Session Teardown 2476 2477 Session teardown may be initiated by either the LAC or LNS and is 2478 accomplished by sending a CDN control message. After the last session 2479 is cleared, the control connection MAY be torn down as well (and 2480 typically is). Following is an example of a typical control message 2481 exchange: 2482 2483 LAC or LNS LAC or LNS 2484 2485 CDN -> 2486 (Clean up) 2487 2488 <- ZLB ACK 2489 (Clean up) 2490 24915.7 Control Connection Teardown 2492 2493 Control connection teardown may be initiated by either the LAC or LNS 2494 and is accomplished by sending a single StopCCN control message. The 2495 receiver of a StopCCN MUST send a ZLB ACK to acknowledge receipt of 2496 the message and maintain enough control connection state to properly 2497 accept StopCCN retransmissions over at least a full retransmission 2498 cycle (in case the ZLB ACK is lost). The recommended time for a full 2499 retransmission cycle is 31 seconds (see section 5.8). Following is an 2500 example of a typical control message exchange: 2501 2502 LAC or LNS LAC or LNS 2503 2504 StopCCN -> 2505 (Clean up) 2506 2507 <- ZLB ACK 2508 (Wait) 2509 (Clean up) 2510 2511 An implementation may shut down an entire tunnel and all sessions on 2512 the tunnel by sending the StopCCN. Thus, it is not necessary to clear 2513 each session individually when tearing down the whole tunnel. 2514 2515 2516 2517 2518 2519 2520 2521 2522Townsley, et al. Standards Track [Page 45] 2523 2524RFC 2661 L2TP August 1999 2525 2526 25275.8 Reliable Delivery of Control Messages 2528 2529 L2TP provides a lower level reliable transport service for all 2530 control messages. The Nr and Ns fields of the control message header 2531 (see section 3.1) belong to this transport. The upper level 2532 functions of L2TP are not concerned with retransmission or ordering 2533 of control messages. The reliable control message is a sliding window 2534 transport that provides control message retransmission and congestion 2535 control. Each peer maintains separate sequence number state for the 2536 control connection within a tunnel. 2537 2538 The message sequence number, Ns, begins at 0. Each subsequent message 2539 is sent with the next increment of the sequence number. The sequence 2540 number is thus a free running counter represented modulo 65536. The 2541 sequence number in the header of a received message is considered 2542 less than or equal to the last received number if its value lies in 2543 the range of the last received number and the preceding 32767 values, 2544 inclusive. For example, if the last received sequence number was 15, 2545 then messages with sequence numbers 0 through 15, as well as 32784 2546 through 65535, would be considered less than or equal. Such a message 2547 would be considered a duplicate of a message already received and 2548 ignored from processing. However, in order to ensure that all 2549 messages are acknowledged properly (particularly in the case of a 2550 lost ZLB ACK message), receipt of duplicate messages MUST be 2551 acknowledged by the reliable transport. This acknowledgement may 2552 either piggybacked on a message in queue, or explicitly via a ZLB 2553 ACK. 2554 2555 All control messages take up one slot in the control message sequence 2556 number space, except the ZLB acknowledgement. Thus, Ns is not 2557 incremented after a ZLB message is sent. 2558 2559 The last received message number, Nr, is used to acknowledge messages 2560 received by an L2TP peer. It contains the sequence number of the 2561 message the peer expects to receive next (e.g. the last Ns of a non- 2562 ZLB message received plus 1, modulo 65536). While the Nr in a 2563 received ZLB is used to flush messages from the local retransmit 2564 queue (see below), Nr of the next message sent is not be updated by 2565 the Ns of the ZLB. 2566 2567 The reliable transport at a receiving peer is responsible for making 2568 sure that control messages are delivered in order and without 2569 duplication to the upper level. Messages arriving out of order may be 2570 queued for in-order delivery when the missing messages are received, 2571 or they may be discarded requiring a retransmission by the peer. 2572 2573 2574 2575 2576 2577 2578Townsley, et al. Standards Track [Page 46] 2579 2580RFC 2661 L2TP August 1999 2581 2582 2583 Each tunnel maintains a queue of control messages to be transmitted 2584 to its peer. The message at the front of the queue is sent with a 2585 given Ns value, and is held until a control message arrives from the 2586 peer in which the Nr field indicates receipt of this message. After a 2587 period of time (a recommended default is 1 second) passes without 2588 acknowledgement, the message is retransmitted. The retransmitted 2589 message contains the same Ns value, but the Nr value MUST be updated 2590 with the sequence number of the next expected message. 2591 2592 Each subsequent retransmission of a message MUST employ an 2593 exponential backoff interval. Thus, if the first retransmission 2594 occurred after 1 second, the next retransmission should occur after 2 2595 seconds has elapsed, then 4 seconds, etc. An implementation MAY place 2596 a cap upon the maximum interval between retransmissions. This cap 2597 MUST be no less than 8 seconds per retransmission. If no peer 2598 response is detected after several retransmissions, (a recommended 2599 default is 5, but SHOULD be configurable), the tunnel and all 2600 sessions within MUST be cleared. 2601 2602 When a tunnel is being shut down for reasons other than loss of 2603 connectivity, the state and reliable delivery mechanisms MUST be 2604 maintained and operated for the full retransmission interval after 2605 the final message exchange has occurred. 2606 2607 A sliding window mechanism is used for control message transmission. 2608 Consider two peers A & B. Suppose A specifies a Receive Window Size 2609 AVP with a value of N in the SCCRQ or SCCRP messages. B is now 2610 allowed to have up to N outstanding control messages. Once N have 2611 been sent, it must wait for an acknowledgment that advances the 2612 window before sending new control messages. An implementation may 2613 support a receive window of only 1 (i.e., by sending out a Receive 2614 Window Size AVP with a value of 1), but MUST accept a window of up to 2615 4 from its peer (e.g. have the ability to send 4 messages before 2616 backing off). A value of 0 for the Receive Window Size AVP is 2617 invalid. 2618 2619 When retransmitting control messages, a slow start and congestion 2620 avoidance window adjustment procedure SHOULD be utilized. The 2621 recommended procedure for this is described in Appendix A. 2622 2623 A peer MUST NOT withhold acknowledgment of messages as a technique 2624 for flow controlling control messages. An L2TP implementation is 2625 expected to be able to keep up with incoming control messages, 2626 possibly responding to some with errors reflecting an inability to 2627 honor the requested action. 2628 2629 Appendix B contains examples of control message transmission, 2630 acknowledgement, and retransmission. 2631 2632 2633 2634Townsley, et al. Standards Track [Page 47] 2635 2636RFC 2661 L2TP August 1999 2637 2638 26396.0 Control Connection Protocol Specification 2640 2641 The following control connection messages are used to establish, 2642 clear and maintain L2TP tunnels. All data is sent in network order 2643 (high order octets first). Any "reserved" or "empty" fields MUST be 2644 sent as 0 values to allow for protocol extensibility. 2645 26466.1 Start-Control-Connection-Request (SCCRQ) 2647 2648 Start-Control-Connection-Request (SCCRQ) is a control message used to 2649 initialize a tunnel between an LNS and an LAC. It is sent by either 2650 the LAC or the LNS to being the tunnel establishment process. 2651 2652 The following AVPs MUST be present in the SCCRQ: 2653 2654 Message Type AVP 2655 Protocol Version 2656 Host Name 2657 Framing Capabilities 2658 Assigned Tunnel ID 2659 2660 The Following AVPs MAY be present in the SCCRQ: 2661 2662 Bearer Capabilities 2663 Receive Window Size 2664 Challenge 2665 Tie Breaker 2666 Firmware Revision 2667 Vendor Name 2668 26696.2 Start-Control-Connection-Reply (SCCRP) 2670 2671 Start-Control-Connection-Reply (SCCRP) is a control message sent in 2672 reply to a received SCCRQ message. SCCRP is used to indicate that the 2673 SCCRQ was accepted and establishment of the tunnel should continue. 2674 2675 The following AVPs MUST be present in the SCCRP: 2676 2677 Message Type 2678 Protocol Version 2679 Framing Capabilities 2680 Host Name 2681 Assigned Tunnel ID 2682 2683 2684 2685 2686 2687 2688 2689 2690Townsley, et al. Standards Track [Page 48] 2691 2692RFC 2661 L2TP August 1999 2693 2694 2695 The following AVPs MAY be present in the SCCRP: 2696 2697 Bearer Capabilities 2698 Firmware Revision 2699 Vendor Name 2700 Receive Window Size 2701 Challenge 2702 Challenge Response 2703 27046.3 Start-Control-Connection-Connected (SCCCN) 2705 2706 Start-Control-Connection-Connected (SCCCN) is a control message sent 2707 in reply to an SCCRP. SCCCN completes the tunnel establishment 2708 process. 2709 2710 The following AVP MUST be present in the SCCCN: 2711 2712 Message Type 2713 2714 The following AVP MAY be present in the SCCCN: 2715 2716 Challenge Response 2717 27186.4 Stop-Control-Connection-Notification (StopCCN) 2719 2720 Stop-Control-Connection-Notification (StopCCN) is a control message 2721 sent by either the LAC or LNS to inform its peer that the tunnel is 2722 being shutdown and the control connection should be closed. In 2723 addition, all active sessions are implicitly cleared (without sending 2724 any explicit call control messages). The reason for issuing this 2725 request is indicated in the Result Code AVP. There is no explicit 2726 reply to the message, only the implicit ACK that is received by the 2727 reliable control message transport layer. 2728 2729 The following AVPs MUST be present in the StopCCN: 2730 2731 Message Type 2732 Assigned Tunnel ID 2733 Result Code 2734 27356.5 Hello (HELLO) 2736 2737 The Hello (HELLO) message is an L2TP control message sent by either 2738 peer of a LAC-LNS control connection. This control message is used as 2739 a "keepalive" for the tunnel. 2740 2741 2742 2743 2744 2745 2746Townsley, et al. Standards Track [Page 49] 2747 2748RFC 2661 L2TP August 1999 2749 2750 2751 The sending of HELLO messages and the policy for sending them are 2752 left up to the implementation. A peer MUST NOT expect HELLO messages 2753 at any time or interval. As with all messages sent on the control 2754 connection, the receiver will return either a ZLB ACK or an 2755 (unrelated) message piggybacking the necessary acknowledgement 2756 information. 2757 2758 Since a HELLO is a control message, and control messages are reliably 2759 sent by the lower level transport, this keepalive function operates 2760 by causing the transport level to reliably deliver a message. If a 2761 media interruption has occurred, the reliable transport will be 2762 unable to deliver the HELLO across, and will clean up the tunnel. 2763 2764 Keepalives for the tunnel MAY be implemented by sending a HELLO if a 2765 period of time (a recommended default is 60 seconds, but SHOULD be 2766 configurable) has passed without receiving any message (data or 2767 control) from the peer. 2768 2769 HELLO messages are global to the tunnel. The Session ID in a HELLO 2770 message MUST be 0. 2771 2772 The Following AVP MUST be present in the HELLO message: 2773 2774 Message Type 2775 27766.6 Incoming-Call-Request (ICRQ) 2777 2778 Incoming-Call-Request (ICRQ) is a control message sent by the LAC to 2779 the LNS when an incoming call is detected. It is the first in a three 2780 message exchange used for establishing a session within an L2TP 2781 tunnel. 2782 2783 ICRQ is used to indicate that a session is to be established between 2784 the LAC and LNS for this call and provides the LNS with parameter 2785 information for the session. The LAC may defer answering the call 2786 until it has received an ICRP from the LNS indicating that the 2787 session should be established. This mechanism allows the LNS to 2788 obtain sufficient information about the call before determining 2789 whether it should be answered or not. Alternatively, the LAC may 2790 answer the call, negotiate LCP and PPP authentication, and use the 2791 information gained to choose the LNS. In this case, the call has 2792 already been answered by the time the ICRP message is received; the 2793 LAC simply spoofs the "call indication" and "call answer" steps in 2794 this case. 2795 2796 2797 2798 2799 2800 2801 2802Townsley, et al. Standards Track [Page 50] 2803 2804RFC 2661 L2TP August 1999 2805 2806 2807 The following AVPs MUST be present in the ICRQ: 2808 2809 Message Type 2810 Assigned Session ID 2811 Call Serial Number 2812 2813 The following AVPs MAY be present in the ICRQ: 2814 2815 Bearer Type 2816 Physical Channel ID 2817 Calling Number 2818 Called Number 2819 Sub-Address 2820 28216.7 Incoming-Call-Reply (ICRP) 2822 2823 Incoming-Call-Reply (ICRP) is a control message sent by the LNS to 2824 the LAC in response to a received ICRQ message. It is the second in 2825 the three message exchange used for establishing sessions within an 2826 L2TP tunnel. 2827 2828 ICRP is used to indicate that the ICRQ was successful and for the LAC 2829 to answer the call if it has not already done so. It also allows the 2830 LNS to indicate necessary parameters for the L2TP session. 2831 2832 The following AVPs MUST be present in the ICRP: 2833 2834 Message Type 2835 Assigned Session ID 2836 28376.8 Incoming-Call-Connected (ICCN) 2838 2839 Incoming-Call-Connected (ICCN) is a control message sent by the LAC 2840 to the LNS in response to a received ICRP message. It is the third 2841 message in the three message exchange used for establishing sessions 2842 within an L2TP tunnel. 2843 2844 ICCN is used to indicate that the ICRP was accepted, the call has 2845 been answered, and that the L2TP session should move to the 2846 established state. It also provides additional information to the 2847 LNS about parameters used for the answered call (parameters that may 2848 not always available at the time the ICRQ is issued). 2849 2850 The following AVPs MUST be present in the ICCN: 2851 2852 Message Type 2853 (Tx) Connect Speed 2854 Framing Type 2855 2856 2857 2858Townsley, et al. Standards Track [Page 51] 2859 2860RFC 2661 L2TP August 1999 2861 2862 2863 The following AVPs MAY be present in the ICCN: 2864 2865 Initial Received LCP CONFREQ 2866 Last Sent LCP CONFREQ 2867 Last Received LCP CONFREQ 2868 Proxy Authen Type 2869 Proxy Authen Name 2870 Proxy Authen Challenge 2871 Proxy Authen ID 2872 Proxy Authen Response 2873 Private Group ID 2874 Rx Connect Speed 2875 Sequencing Required 2876 28776.9 Outgoing-Call-Request (OCRQ) 2878 2879 Outgoing-Call-Request (OCRQ) is a control message sent by the LNS to 2880 the LAC to indicate that an outbound call from the LAC is to be 2881 established. It is the first in a three message exchange used for 2882 establishing a session within an L2TP tunnel. 2883 2884 OCRQ is used to indicate that a session is to be established between 2885 the LNS and LAC for this call and provides the LAC with parameter 2886 information for both the L2TP session, and the call that is to be 2887 placed 2888 2889 An LNS MUST have received a Bearer Capabilities AVP during tunnel 2890 establishment from an LAC in order to request an outgoing call to 2891 that LAC. 2892 2893 The following AVPs MUST be present in the OCRQ: 2894 2895 Message Type 2896 Assigned Session ID 2897 Call Serial Number 2898 Minimum BPS 2899 Maximum BPS 2900 Bearer Type 2901 Framing Type 2902 Called Number 2903 2904 The following AVPs MAY be present in the OCRQ: 2905 2906 Sub-Address 2907 2908 2909 2910 2911 2912 2913 2914Townsley, et al. Standards Track [Page 52] 2915 2916RFC 2661 L2TP August 1999 2917 2918 29196.10 Outgoing-Call-Reply (OCRP) 2920 2921 Outgoing-Call-Reply (OCRP) is a control message sent by the LAC to 2922 the LNS in response to a received OCRQ message. It is the second in a 2923 three message exchange used for establishing a session within an L2TP 2924 tunnel. 2925 2926 OCRP is used to indicate that the LAC is able to attempt the outbound 2927 call and returns certain parameters regarding the call attempt. 2928 2929 The following AVPs MUST be present in the OCRP: 2930 2931 Message Type 2932 Assigned Session ID 2933 2934 The following AVPs MAY be present in the OCRP: 2935 2936 Physical Channel ID 2937 29386.11 Outgoing-Call-Connected (OCCN) 2939 2940 Outgoing-Call-Connected (OCCN) is a control message sent by the LAC 2941 to the LNS following the OCRP and after the outgoing call has been 2942 completed. It is the final message in a three message exchange used 2943 for establishing a session within an L2TP tunnel. 2944 2945 OCCN is used to indicate that the result of a requested outgoing call 2946 was successful. It also provides information to the LNS about the 2947 particular parameters obtained after the call was established. 2948 2949 The following AVPs MUST be present in the OCCN: 2950 2951 Message Type 2952 (Tx) Connect Speed 2953 Framing Type 2954 2955 The following AVPs MAY be present in the OCCN: 2956 2957 Rx Connect Speed 2958 Sequencing Required 2959 29606.12 Call-Disconnect-Notify (CDN) 2961 2962 The Call-Disconnect-Notify (CDN) message is an L2TP control message 2963 sent by either the LAC or LNS to request disconnection of a specific 2964 call within the tunnel. Its purpose is to inform the peer of the 2965 2966 2967 2968 2969 2970Townsley, et al. Standards Track [Page 53] 2971 2972RFC 2661 L2TP August 1999 2973 2974 2975 disconnection and the reason why the disconnection occurred. The peer 2976 MUST clean up any resources, and does not send back any indication of 2977 success or failure for such cleanup. 2978 2979 The following AVPs MUST be present in the CDN: 2980 2981 Message Type 2982 Result Code 2983 Assigned Session ID 2984 2985 The following AVPs MAY be present in the CDN: 2986 2987 Q.931 Cause Code 2988 29896.13 WAN-Error-Notify (WEN) 2990 2991 The WAN-Error-Notify message is an L2TP control message sent by the 2992 LAC to the LNS to indicate WAN error conditions (conditions that 2993 occur on the interface supporting PPP). The counters in this message 2994 are cumulative. This message should only be sent when an error 2995 occurs, and not more than once every 60 seconds. The counters are 2996 reset when a new call is established. 2997 2998 The following AVPs MUST be present in the WEN: 2999 3000 Message Type 3001 Call Errors 3002 30036.14 Set-Link-Info (SLI) 3004 3005 The Set-Link-Info message is an L2TP control message sent by the LNS 3006 to the LAC to set PPP-negotiated options. These options can change 3007 at any time during the life of the call, thus the LAC MUST be able to 3008 update its internal call information and behavior on an active PPP 3009 session. 3010 3011 The following AVPs MUST be present in the SLI: 3012 3013 Message Type 3014 ACCM 3015 30167.0 Control Connection State Machines 3017 3018 The control messages defined in section 6 are exchanged by way of 3019 state tables defined in this section. Tables are defined for incoming 3020 call placement, outgoing call placement, as well as for initiation of 3021 3022 3023 3024 3025 3026Townsley, et al. Standards Track [Page 54] 3027 3028RFC 2661 L2TP August 1999 3029 3030 3031 the tunnel itself. The state tables do not encode timeout and 3032 retransmission behavior, as this is handled in the underlying 3033 semantics defined in Section 5.8. 3034 30357.1 Control Connection Protocol Operation 3036 3037 This section describes the operation of various L2TP control 3038 connection functions and the Control Connection messages which are 3039 used to support them. 3040 3041 Receipt of an invalid or unrecoverable malformed control message 3042 should be logged appropriately and the control connection cleared to 3043 ensure recovery to a known state. The control connection may then be 3044 restarted by the initiator. 3045 3046 An invalid control message is defined as a message which contains a 3047 Message Type that is marked mandatory (see Section 4.4.1) and is 3048 unknown to the implementation, or a control message that is received 3049 in an improper sequence (e.g. an SCCCN sent in reply to an SCCRQ). 3050 3051 Examples of a malformed control message include one that has an 3052 invalid value in its header, contains an AVP that is formatted 3053 incorrectly or whose value is out of range, or a message that is 3054 missing a required AVP. A control message with a malformed header 3055 should be discarded. A control message with an invalid AVP should 3056 look to the M-bit for that AVP to determine whether the error is 3057 recoverable or not. 3058 3059 A malformed yet recoverable non-mandatory (M-bit is not set) AVP 3060 within a control message should be treated in a similar manner as an 3061 unrecognized non-mandatory AVP. Thus, if a malformed AVP is received 3062 with the M-bit set, the session or tunnel should be terminated with a 3063 proper Result or Error Code sent. If the M-bit is not set, the AVP 3064 should be ignored (with the exception of logging a local error 3065 message) and the message accepted. 3066 3067 This MUST NOT be considered a license to send malformed AVPs, but 3068 simply a guide towards how to handle an improperly formatted message 3069 if one is received. It is impossible to list all potential 3070 malformations of a given message and give advice for each. That said, 3071 one example of a recoverable, malformed AVP might be if the Rx 3072 Connect Speed AVP, attribute 38, is received with a length of 8 3073 rather than 10 and the BPS given in 2 octets rather than 4. Since the 3074 Rx Connect Speed is non-mandatory, this condition should not be 3075 considered catastrophic. As such, the control message should be 3076 accepted as if the AVP had not been received (with the exception of a 3077 local error message being logged). 3078 3079 3080 3081 3082Townsley, et al. Standards Track [Page 55] 3083 3084RFC 2661 L2TP August 1999 3085 3086 3087 In several cases in the following tables, a protocol message is sent, 3088 and then a "clean up" occurs. Note that regardless of the initiator 3089 of the tunnel destruction, the reliable delivery mechanism must be 3090 allowed to run (see Section 5.8) before destroying the tunnel. This 3091 permits the tunnel management messages to be reliably delivered to 3092 the peer. 3093 3094 Appendix B.1 contains an example of lock-step tunnel establishment. 3095 30967.2 Control Connection States 3097 3098 The L2TP control connection protocol is not distinguishable between 3099 the LNS and LAC, but is distinguishable between the originator and 3100 receiver. The originating peer is the one which first initiates 3101 establishment of the tunnel (in a tie breaker situation, this is the 3102 winner of the tie). Since either LAC or LNS can be the originator, a 3103 collision can occur. See the Tie Breaker AVP in Section 4.4.3 for a 3104 description of this and its resolution. 3105 31067.2.1 Control Connection Establishment 3107 3108 State Event Action New State 3109 ----- ----- ------ --------- 3110 idle Local Send SCCRQ wait-ctl-reply 3111 Open request 3112 3113 idle Receive SCCRQ, Send SCCRP wait-ctl-conn 3114 acceptable 3115 3116 idle Receive SCCRQ, Send StopCCN, idle 3117 not acceptable Clean up 3118 3119 idle Receive SCCRP Send StopCCN idle 3120 Clean up 3121 3122 idle Receive SCCCN Clean up idle 3123 3124 wait-ctl-reply Receive SCCRP, Send SCCCN, established 3125 acceptable Send tunnel-open 3126 event to waiting 3127 sessions 3128 3129 wait-ctl-reply Receive SCCRP, Send StopCCN, idle 3130 not acceptable Clean up 3131 3132 wait-ctl-reply Receive SCCRQ, Clean up, idle 3133 lose tie-breaker Re-queue SCCRQ 3134 for idle state 3135 3136 3137 3138Townsley, et al. Standards Track [Page 56] 3139 3140RFC 2661 L2TP August 1999 3141 3142 3143 wait-ctl-reply Receive SCCCN Send StopCCN idle 3144 Clean up 3145 3146 wait-ctl-conn Receive SCCCN, Send tunnel-open established 3147 acceptable event to waiting 3148 sessions 3149 3150 wait-ctl-conn Receive SCCCN, Send StopCCN, idle 3151 not acceptable Clean up 3152 3153 wait-ctl-conn Receive SCCRP, Send StopCCN, idle 3154 SCCRQ Clean up 3155 3156 established Local Send tunnel-open established 3157 Open request event to waiting 3158 (new call) sessions 3159 3160 established Admin Send StopCCN idle 3161 Tunnel Close Clean up 3162 3163 established Receive SCCRQ, Send StopCCN idle 3164 SCCRP, SCCCN Clean up 3165 3166 idle Receive StopCCN Clean up idle 3167 wait-ctl-reply, 3168 wait-ctl-conn, 3169 established 3170 3171 The states associated with the LNS or LAC for control connection 3172 establishment are: 3173 3174 idle 3175 Both initiator and recipient start from this state. An initiator 3176 transmits an SCCRQ, while a recipient remains in the idle state 3177 until receiving an SCCRQ. 3178 3179 wait-ctl-reply 3180 The originator checks to see if another connection has been 3181 requested from the same peer, and if so, handles the collision 3182 situation described in Section 5.8. 3183 3184 When an SCCRP is received, it is examined for a compatible 3185 version. If the version of the reply is lower than the version 3186 sent in the request, the older (lower) version should be used 3187 provided it is supported. If the version in the reply is earlier 3188 and supported, the originator moves to the established state. If 3189 3190 3191 3192 3193 3194Townsley, et al. Standards Track [Page 57] 3195 3196RFC 2661 L2TP August 1999 3197 3198 3199 the version is earlier and not supported, a StopCCN MUST be sent 3200 to the peer and the originator cleans up and terminates the 3201 tunnel. 3202 3203 wait-ctl-conn 3204 This is where an SCCCN is awaited; upon receipt, the challenge 3205 response is checked. The tunnel either is established, or is torn 3206 down if an authorization failure is detected. 3207 3208 established 3209 An established connection may be terminated by either a local 3210 condition or the receipt of a Stop-Control-Connection- 3211 Notification. In the event of a local termination, the originator 3212 MUST send a Stop-Control-Connection-Notification and clean up the 3213 tunnel. 3214 3215 If the originator receives a Stop-Control-Connection-Notification 3216 it MUST also clean up the tunnel. 3217 32187.3 Timing considerations 3219 3220 Due to the real-time nature of telephone signaling, both the LNS and 3221 LAC should be implemented with multi-threaded architectures such that 3222 messages related to multiple calls are not serialized and blocked. 3223 The call and connection state figures do not specify exceptions 3224 caused by timers. These are addressed in Section 5.8. 3225 32267.4 Incoming calls 3227 3228 An Incoming-Call-Request message is generated by the LAC when an 3229 incoming call is detected (for example, an associated telephone line 3230 rings). The LAC selects a Session ID and serial number and indicates 3231 the call bearer type. Modems should always indicate analog call type. 3232 ISDN calls should indicate digital when unrestricted digital service 3233 or rate adaption is used and analog if digital modems are involved. 3234 Calling Number, Called Number, and Subaddress may be included in the 3235 message if they are available from the telephone network. 3236 3237 Once the LAC sends the Incoming-Call-Request, it waits for a response 3238 from the LNS but it does not necessarily answer the call from the 3239 telephone network yet. The LNS may choose not to accept the call if: 3240 3241 - No resources are available to handle more sessions 3242 - The dialed, dialing, or subaddress fields do not correspond to 3243 an authorized user 3244 - The bearer service is not authorized or supported 3245 3246 3247 3248 3249 3250Townsley, et al. Standards Track [Page 58] 3251 3252RFC 2661 L2TP August 1999 3253 3254 3255 If the LNS chooses to accept the call, it responds with an Incoming- 3256 Call-Reply. When the LAC receives the Incoming-Call-Reply, it 3257 attempts to connect the call. A final call connected message from 3258 the LAC to the LNS indicates that the call states for both the LAC 3259 and the LNS should enter the established state. If the call 3260 terminated before the LNS could accept it, a Call-Disconnect-Notify 3261 is sent by the LAC to indicate this condition. 3262 3263 When the dialed-in client hangs up, the call is cleared normally and 3264 the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to 3265 clear a call, it sends a Call-Disconnect-Notify message and cleans up 3266 its session. 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306Townsley, et al. Standards Track [Page 59] 3307 3308RFC 2661 L2TP August 1999 3309 3310 33117.4.1 LAC Incoming Call States 3312 3313 State Event Action New State 3314 ----- ----- ------ --------- 3315 idle Bearer Ring or Initiate local wait-tunnel 3316 Ready to indicate tunnel open 3317 incoming conn. 3318 3319 idle Receive ICCN, Clean up idle 3320 ICRP, CDN 3321 3322 wait-tunnel Bearer line drop Clean up idle 3323 or local close 3324 request 3325 3326 wait-tunnel tunnel-open Send ICRQ wait-reply 3327 3328 wait-reply Receive ICRP, Send ICCN established 3329 acceptable 3330 3331 wait-reply Receive ICRP, Send CDN, idle 3332 Not acceptable Clean up 3333 3334 wait-reply Receive ICRQ Send CDN idle 3335 Clean up 3336 3337 wait-reply Receive CDN Clean up idle 3338 ICCN 3339 3340 wait-reply Local Send CDN, idle 3341 close request or Clean up 3342 Bearer line drop 3343 3344 established Receive CDN Clean up idle 3345 3346 established Receive ICRQ, Send CDN, idle 3347 ICRP, ICCN Clean up 3348 3349 established Bearer line Send CDN, idle 3350 drop or local Clean up 3351 close request 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362Townsley, et al. Standards Track [Page 60] 3363 3364RFC 2661 L2TP August 1999 3365 3366 3367 The states associated with the LAC for incoming calls are: 3368 3369 idle 3370 The LAC detects an incoming call on one of its interfaces. 3371 Typically this means an analog line is ringing or an ISDN TE has 3372 detected an incoming Q.931 SETUP message. The LAC initiates its 3373 tunnel establishment state machine, and moves to a state waiting 3374 for confirmation of the existence of a tunnel. 3375 3376 wait-tunnel 3377 In this state the session is waiting for either the control 3378 connection to be opened or for verification that the tunnel is 3379 already open. Once an indication that the tunnel has/was opened, 3380 session control messages may be exchanged. The first of these is 3381 the Incoming-Call-Request. 3382 3383 wait-reply 3384 The LAC receives either a CDN message indicating the LNS is not 3385 willing to accept the call (general error or don't accept) and 3386 moves back into the idle state, or an Incoming-Call-Reply message 3387 indicating the call is accepted, the LAC sends an Incoming-Call- 3388 Connected message and enters the established state. 3389 3390 established 3391 Data is exchanged over the tunnel. The call may be cleared 3392 following: 3393 + An event on the connected interface: The LAC sends a Call- 3394 Disconnect-Notify message 3395 + Receipt of a Call-Disconnect-Notify message: The LAC cleans 3396 up, disconnecting the call. 3397 + A local reason: The LAC sends a Call-Disconnect-Notify 3398 message. 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418Townsley, et al. Standards Track [Page 61] 3419 3420RFC 2661 L2TP August 1999 3421 3422 34237.4.2 LNS Incoming Call States 3424 3425 State Event Action New State 3426 ----- ----- ------ --------- 3427 idle Receive ICRQ, Send ICRP wait-connect 3428 acceptable 3429 3430 idle Receive ICRQ, Send CDN, idle 3431 not acceptable Clean up 3432 3433 idle Receive ICRP Send CDN idle 3434 Clean up 3435 3436 idle Receive ICCN Clean up idle 3437 3438 wait-connect Receive ICCN Prepare for established 3439 acceptable data 3440 3441 wait-connect Receive ICCN Send CDN, idle 3442 not acceptable Clean up 3443 3444 wait-connect Receive ICRQ, Send CDN idle 3445 ICRP Clean up 3446 3447 idle, Receive CDN Clean up idle 3448 wait-connect, 3449 established 3450 3451 wait-connect Local Send CDN, idle 3452 established Close request Clean up 3453 3454 established Receive ICRQ, Send CDN idle 3455 ICRP, ICCN Clean up 3456 3457 The states associated with the LNS for incoming calls are: 3458 3459 idle 3460 An Incoming-Call-Request message is received. If the request is 3461 not acceptable, a Call-Disconnect-Notify is sent back to the LAC 3462 and the LNS remains in the idle state. If the Incoming-Call- 3463 Request message is acceptable, an Incoming-Call-Reply is sent. The 3464 session moves to the wait-connect state. 3465 3466 wait-connect 3467 If the session is still connected on the LAC, the LAC sends an 3468 Incoming-Call-Connected message to the LNS which then moves into 3469 established state. The LAC may send a Call-Disconnect-Notify to 3470 indicate that the incoming caller could not be connected. This 3471 3472 3473 3474Townsley, et al. Standards Track [Page 62] 3475 3476RFC 2661 L2TP August 1999 3477 3478 3479 could happen, for example, if a telephone user accidentally places 3480 a standard voice call to an LAC resulting in a handshake failure 3481 on the called modem. 3482 3483 established 3484 The session is terminated either by receipt of a Call-Disconnect- 3485 Notify message from the LAC or by sending a Call-Disconnect- 3486 Notify. Clean up follows on both sides regardless of the 3487 initiator. 3488 34897.5 Outgoing calls 3490 3491 Outgoing calls are initiated by an LNS and instruct an LAC to place a 3492 call. There are three messages for outgoing calls: Outgoing-Call- 3493 Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS 3494 sends an Outgoing-Call-Request specifying the dialed party phone 3495 number, subaddress and other parameters. The LAC MUST respond to the 3496 Outgoing-Call-Request message with an Outgoing-Call-Reply message 3497 once the LAC determines that the proper facilities exist to place the 3498 call and the call is administratively authorized. For example, is 3499 this LNS allowed to dial an international call? Once the outbound 3500 call is connected, the LAC sends an Outgoing-Call-Connected message 3501 to the LNS indicating the final result of the call attempt: 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530Townsley, et al. Standards Track [Page 63] 3531 3532RFC 2661 L2TP August 1999 3533 3534 35357.5.1 LAC Outgoing Call States 3536 3537 State Event Action New State 3538 ----- ----- ------ --------- 3539 idle Receive OCRQ, Send OCRP, wait-cs-answer 3540 acceptable Open bearer 3541 3542 idle Receive OCRQ, Send CDN, idle 3543 not acceptable Clean up 3544 3545 idle Receive OCRP Send CDN idle 3546 Clean up 3547 3548 idle Receive OCCN, Clean up idle 3549 CDN 3550 3551 wait-cs-answer Bearer answer, Send OCCN established 3552 framing detected 3553 3554 wait-cs-answer Bearer failure Send CDN, idle 3555 Clean up 3556 3557 wait-cs-answer Receive OCRQ, Send CDN idle 3558 OCRP, OCCN Clean up 3559 3560 established Receive OCRQ, Send CDN idle 3561 OCRP, OCCN Clean up 3562 3563 wait-cs-answer, Receive CDN Clean up idle 3564 established 3565 3566 established Bearer line drop, Send CDN, idle 3567 Local close Clean up 3568 request 3569 3570 The states associated with the LAC for outgoing calls are: 3571 3572 idle 3573 If Outgoing-Call-Request is received in error, respond with a 3574 Call-Disconnect-Notify. Otherwise, allocate a physical channel and 3575 send an Outgoing-Call-Reply. Place the outbound call and move to 3576 the wait-cs-answer state. 3577 3578 wait-cs-answer 3579 If the call is not completed or a timer expires waiting for the 3580 call to complete, send a Call-Disconnect-Notify with the 3581 appropriate error condition set and go to idle state. If a circuit 3582 3583 3584 3585 3586Townsley, et al. Standards Track [Page 64] 3587 3588RFC 2661 L2TP August 1999 3589 3590 3591 switched connection is established and framing is detected, send 3592 an Outgoing-Call-Connected indicating success and go to 3593 established state. 3594 3595 established 3596 If a Call-Disconnect-Notify is received by the LAC, the telco call 3597 MUST be released via appropriate mechanisms and the session 3598 cleaned up. If the call is disconnected by the client or the 3599 called interface, a Call-Disconnect-Notify message MUST be sent to 3600 the LNS. The sender of the Call-Disconnect-Notify message returns 3601 to the idle state after sending of the message is complete. 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642Townsley, et al. Standards Track [Page 65] 3643 3644RFC 2661 L2TP August 1999 3645 3646 36477.5.2 LNS Outgoing Call States 3648 3649 State Event Action New State 3650 ----- ----- ------ --------- 3651 idle Local Initiate local wait-tunnel 3652 open request tunnel-open 3653 3654 idle Receive OCCN, Clean up idle 3655 OCRP, CDN 3656 3657 wait-tunnel tunnel-open Send OCRQ wait-reply 3658 3659 wait-reply Receive OCRP, none wait-connect 3660 acceptable 3661 3662 wait-reply Receive OCRP, Send CDN idle 3663 not acceptable Clean up 3664 3665 wait-reply Receive OCCN, Send CDN idle 3666 OCRQ Clean up 3667 3668 wait-connect Receive OCCN none established 3669 3670 wait-connect Receive OCRQ, Send CDN idle 3671 OCRP Clean up 3672 3673 idle, Receive CDN, Clean up idle 3674 wait-reply, 3675 wait-connect, 3676 established 3677 3678 established Receive OCRQ, Send CDN idle 3679 OCRP, OCCN Clean up 3680 3681 wait-reply, Local Send CDN idle 3682 wait-connect, Close request Clean up 3683 established 3684 3685 wait-tunnel Local Clean up idle 3686 Close request 3687 3688 The states associated with the LNS for outgoing calls are: 3689 3690 idle, wait-tunnel 3691 When an outgoing call is initiated, a tunnel is first created, 3692 much as the idle and wait-tunnel states for an LAC incoming call. 3693 Once a tunnel is established, an Outgoing-Call-Request message is 3694 sent to the LAC and the session moves into the wait-reply state. 3695 3696 3697 3698Townsley, et al. Standards Track [Page 66] 3699 3700RFC 2661 L2TP August 1999 3701 3702 3703 wait-reply 3704 If a Call-Disconnect-Notify is received, an error occurred, and 3705 the session is cleaned up and returns to idle. If an Outgoing- 3706 Call-Reply is received, the call is in progress and the session 3707 moves to the wait-connect state. 3708 3709 wait-connect 3710 If a Call-Disconnect-Notify is received, the call failed; the 3711 session is cleaned up and returns to idle. If an Outgoing-Call- 3712 Connected is received, the call has succeeded and the session may 3713 now exchange data. 3714 3715 established 3716 If a Call-Disconnect-Notify is received, the call has been 3717 terminated for the reason indicated in the Result and Cause Codes; 3718 the session moves back to the idle state. If the LNS chooses to 3719 terminate the session, it sends a Call-Disconnect-Notify to the 3720 LAC and then cleans up and idles its session. 3721 37227.6 Tunnel Disconnection 3723 3724 The disconnection of a tunnel consists of either peer issuing a 3725 Stop-Control-Connection-Notification. The sender of this Notification 3726 should wait a finite period of time for the acknowledgment of this 3727 message before releasing the control information associated with the 3728 tunnel. The recipient of this Notification should send an 3729 acknowledgment of the Notification and then release the associated 3730 control information. 3731 3732 When to release a tunnel is an implementation issue and is not 3733 specified in this document. A particular implementation may use 3734 whatever policy is appropriate for determining when to release a 3735 control connection. Some implementations may leave a tunnel open for 3736 a period of time or perhaps indefinitely after the last session for 3737 that tunnel is cleared. Others may choose to disconnect the tunnel 3738 immediately after the last user connection on the tunnel disconnects. 3739 37408.0 L2TP Over Specific Media 3741 3742 L2TP is self-describing, operating at a level above the media over 3743 which it is carried. However, some details of its connection to media 3744 are required to permit interoperable implementations. The following 3745 sections describe details needed to permit interoperability over 3746 specific media. 3747 3748 3749 3750 3751 3752 3753 3754Townsley, et al. Standards Track [Page 67] 3755 3756RFC 2661 L2TP August 1999 3757 3758 37598.1 L2TP over UDP/IP 3760 3761 L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP 3762 packet, including payload and L2TP header, is sent within a UDP 3763 datagram. The initiator of an L2TP tunnel picks an available source 3764 UDP port (which may or may not be 1701), and sends to the desired 3765 destination address at port 1701. The recipient picks a free port on 3766 its own system (which may or may not be 1701), and sends its reply to 3767 the initiator's UDP port and address, setting its own source port to 3768 the free port it found. Once the source and destination ports and 3769 addresses are established, they MUST remain static for the life of 3770 the tunnel. 3771 3772 It has been suggested that having the recipient choose an arbitrary 3773 source port (as opposed to using the destination port in the packet 3774 initiating the tunnel, i.e., 1701) may make it more difficult for 3775 L2TP to traverse some NAT devices. Implementors should consider the 3776 potential implication of this before before choosing an arbitrary 3777 source port. 3778 3779 IP fragmentation may occur as the L2TP packet travels over the IP 3780 substrate. L2TP makes no special efforts to optimize this. A LAC 3781 implementation MAY cause its LCP to negotiate for a specific MRU, 3782 which could optimize for LAC environments in which the MTU's of the 3783 path over which the L2TP packets are likely to travel have a 3784 consistent value. 3785 3786 The default for any L2TP implementation is that UDP checksums MUST be 3787 enabled for both control and data messages. An L2TP implementation 3788 MAY provide an option to disable UDP checksums for data messages. It 3789 is recommended that UDP checksums always be enabled on control 3790 packets. 3791 3792 Port 1701 is used for both L2F [RFC2341] and L2TP packets. The 3793 Version field in each header may be used to discriminate between the 3794 two packet types (L2F uses a value of 1, and the L2TP version 3795 described in this document uses a value of 2). An L2TP implementation 3796 running on a system which does not support L2F MUST silently discard 3797 all L2F packets. 3798 3799 To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP link has 3800 the characteristic of being able to reorder or silently drop packets. 3801 The former may break non-IP protocols being carried by PPP, 3802 especially LAN-centric ones such as bridging. The latter may break 3803 protocols which assume per-packet indication of error, such as TCP 3804 header compression. Sequencing may be handled by using L2TP data 3805 message sequence numbers if any protocol being transported by the PPP 3806 3807 3808 3809 3810Townsley, et al. Standards Track [Page 68] 3811 3812RFC 2661 L2TP August 1999 3813 3814 3815 tunnel cannot tolerate reordering. The sequence dependency 3816 characteristics of individual protocols are outside the scope of this 3817 document. 3818 3819 Allowing packets to be dropped silently is perhaps more problematic 3820 with some protocols. If PPP reliable delivery [RFC1663] is enabled, 3821 no upper PPP protocol will encounter lost packets. If L2TP sequence 3822 numbers are enabled, L2TP can detect the packet loss. In the case of 3823 an LNS, the PPP and L2TP stacks are both present within the LNS, and 3824 packet loss signaling may occur precisely as if a packet was received 3825 with a CRC error. Where the LAC and PPP stack are co-resident, this 3826 technique also applies. Where the LAC and PPP client are physically 3827 distinct, the analogous signaling MAY be accomplished by sending a 3828 packet with a CRC error to the PPP client. Note that this would 3829 greatly increase the complexity of debugging client line problems, 3830 since the client statistics could not distinguish between true media 3831 errors and LAC-initiated ones. Further, this technique is not 3832 possible on all hardware. 3833 3834 If VJ compression is used, and neither PPP reliable delivery nor 3835 sequence numbers are enabled, each lost packet results in a 1 in 3836 2**16 chance of a TCP segment being forwarded with incorrect contents 3837 [RFC1144]. Where the combination of the packet loss rate with this 3838 statistical exposure is unacceptable, TCP header compression SHOULD 3839 NOT be used. 3840 3841 In general, it is wise to remember that the L2TP/UDP/IP transport is 3842 an unreliable transport. As with any PPP media that is subject to 3843 loss, care should be taken when using protocols that are particularly 3844 loss-sensitive. Such protocols include compression and encryption 3845 protocols that employ history. 3846 38478.2 IP 3848 3849 When operating in IP environments, L2TP MUST offer the UDP 3850 encapsulation described in 8.1 as its default configuration for IP 3851 operation. Other configurations (perhaps corresponding to a 3852 compressed header format) MAY be defined and made available as a 3853 configurable option. 3854 38559.0 Security Considerations 3856 3857 L2TP encounters several security issues in its operation. The 3858 general approach of L2TP to these issues is documented here. 3859 3860 3861 3862 3863 3864 3865 3866Townsley, et al. Standards Track [Page 69] 3867 3868RFC 2661 L2TP August 1999 3869 3870 38719.1 Tunnel Endpoint Security 3872 3873 The tunnel endpoints may optionally perform an authentication 3874 procedure of one another during tunnel establishment. This 3875 authentication has the same security attributes as CHAP, and has 3876 reasonable protection against replay and snooping during the tunnel 3877 establishment process. This mechanism is not designed to provide any 3878 authentication beyond tunnel establishment; it is fairly simple for a 3879 malicious user who can snoop the tunnel stream to inject packets once 3880 an authenticated tunnel establishment has been completed 3881 successfully. 3882 3883 For authentication to occur, the LAC and LNS MUST share a single 3884 secret. Each side uses this same secret when acting as authenticatee 3885 as well as authenticator. Since a single secret is used, the tunnel 3886 authentication AVPs include differentiating values in the CHAP ID 3887 fields for each message digest calculation to guard against replay 3888 attacks. 3889 3890 The Assigned Tunnel ID and Assigned Session ID (See Section 4.4.3) 3891 SHOULD be selected in an unpredictable manner rather than 3892 sequentially or otherwise. Doing so will help deter hijacking of a 3893 session by a malicious user who does not have access to packet traces 3894 between the LAC and LNS. 3895 38969.2 Packet Level Security 3897 3898 Securing L2TP requires that the underlying transport make available 3899 encryption, integrity and authentication services for all L2TP 3900 traffic. This secure transport operates on the entire L2TP packet 3901 and is functionally independent of PPP and the protocol being carried 3902 by PPP. As such, L2TP is only concerned with confidentiality, 3903 authenticity, and integrity of the L2TP packets between its tunnel 3904 3905 endpoints (the LAC and LNS), not unlike link-layer encryption being 3906 concerned only about protecting the confidentiality of traffic 3907 between its physical endpoints. 3908 39099.3 End to End Security 3910 3911 Protecting the L2TP packet stream via a secure transport does, in 3912 turn, also protect the data within the tunneled PPP packets while 3913 transported from the LAC to the LNS. Such protection should not be 3914 considered a substitution for end-to-end security between 3915 communicating hosts or applications. 3916 3917 3918 3919 3920 3921 3922Townsley, et al. Standards Track [Page 70] 3923 3924RFC 2661 L2TP August 1999 3925 3926 39279.4 L2TP and IPsec 3928 3929 When running over IP, IPsec provides packet-level security via ESP 3930 and/or AH. All L2TP control and data packets for a particular tunnel 3931 appear as homogeneous UDP/IP data packets to the IPsec system. 3932 3933 In addition to IP transport security, IPsec defines a mode of 3934 operation that allows tunneling of IP packets. The packet level 3935 encryption and authentication provided by IPsec tunnel mode and that 3936 provided by L2TP secured with IPsec provide an equivalent level of 3937 security for these requirements. 3938 3939 IPsec also defines access control features that are required of a 3940 compliant IPsec implementation. These features allow filtering of 3941 packets based upon network and transport layer characteristics such 3942 as IP address, ports, etc. In the L2TP tunneling model, analogous 3943 filtering is logically performed at the PPP layer or network layer 3944 above L2TP. These network layer access control features may be 3945 handled at the LNS via vendor-specific authorization features based 3946 upon the authenticated PPP user, or at the network layer itself by 3947 using IPsec transport mode end-to-end between the communicating 3948 hosts. The requirements for access control mechanisms are not a part 3949 of the L2TP specification and as such are outside the scope of this 3950 document. 3951 39529.5 Proxy PPP Authentication 3953 3954 L2TP defines AVPs that MAY be exchanged during session establishment 3955 to provide forwarding of PPP authentication information obtained at 3956 the LAC to the LNS for validation (see Section 4.4.5). This implies a 3957 direct trust relationship of the LAC on behalf of the LNS. If the 3958 LNS chooses to implement proxy authentication, it MUST be able to be 3959 configured off, requiring a new round a PPP authentication initiated 3960 by the LNS (which may or may not include a new round of LCP 3961 negotiation). 3962 396310.0 IANA Considerations 3964 3965 This document defines a number of "magic" numbers to be maintained by 3966 the IANA. This section explains the criteria to be used by the IANA 3967 to assign additional numbers in each of these lists. The following 3968 subsections describe the assignment policy for the namespaces defined 3969 elsewhere in this document. 3970 397110.1 AVP Attributes 3972 3973 As defined in Section 4.1, AVPs contain vendor ID, Attribute and 3974 Value fields. For vendor ID value of 0, IANA will maintain a registry 3975 3976 3977 3978Townsley, et al. Standards Track [Page 71] 3979 3980RFC 2661 L2TP August 1999 3981 3982 3983 of assigned Attributes and in some case also values. Attributes 0-39 3984 are assigned as defined in Section 4.4. The remaining values are 3985 available for assignment through IETF Consensus [RFC 2434]. 3986 398710.2 Message Type AVP Values 3988 3989 As defined in Section 4.4.1, Message Type AVPs (Attribute Type 0) 3990 have an associated value maintained by IANA. Values 0-16 are defined 3991 in Section 3.2, the remaining values are available for assignment via 3992 IETF Consensus [RFC 2434] 3993 399410.3 Result Code AVP Values 3995 3996 As defined in Section 4.4.2, Result Code AVPs (Attribute Type 1) 3997 contain three fields. Two of these fields (the Result Code and Error 3998 Code fields) have associated values maintained by IANA. 3999 400010.3.1 Result Code Field Values 4001 4002 The Result Code AVP may be included in CDN and StopCCN messages. The 4003 allowable values for the Result Code field of the AVP differ 4004 depending upon the value of the Message Type AVP. For the StopCCN 4005 message, values 0-7 are defined in Section 4.4.2; for the StopCCN 4006 message, values 0-11 are defined in the same section. The remaining 4007 values of the Result Code field for both messages are available for 4008 assignment via IETF Consensus [RFC 2434]. 4009 401010.3.2 Error Code Field Values 4011 4012 Values 0-7 are defined in Section 4.4.2. Values 8-32767 are 4013 available for assignment via IETF Consensus [RFC 2434]. The remaining 4014 values of the Error Code field are available for assignment via First 4015 Come First Served [RFC 2434]. 4016 401710.4 Framing Capabilities & Bearer Capabilities 4018 4019 The Framing Capabilities AVP and Bearer Capabilities AVPs (defined in 4020 Section 4.4.3) both contain 32-bit bitmasks. Additional bits should 4021 only be defined via a Standards Action [RFC 2434]. 4022 402310.5 Proxy Authen Type AVP Values 4024 4025 The Proxy Authen Type AVP (Attribute Type 29) has an associated value 4026 maintained by IANA. Values 0-5 are defined in Section 4.4.5, the 4027 remaining values are available for assignment via First Come First 4028 Served [RFC 2434]. 4029 4030 4031 4032 4033 4034Townsley, et al. Standards Track [Page 72] 4035 4036RFC 2661 L2TP August 1999 4037 4038 403910.6 AVP Header Bits 4040 4041 There are four remaining reserved bits in the AVP header. Additional 4042 bits should only be assigned via a Standards Action [RFC 2434]. 4043 404411.0 References 4045 4046 [DSS1] ITU-T Recommendation, "Digital subscriber Signaling System 4047 No. 1 (DSS 1) - ISDN user-network interface layer 3 4048 specification for basic call control", Rec. Q.931(I.451), 4049 May 1998 4050 4051 [KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network 4052 Security: Private Communications in a Public World", 4053 Prentice Hall, March 1995, ISBN 0-13-061466-1 4054 4055 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 4056 1981. 4057 4058 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 4059 STD 13, RFC 1034, November 1987. 4060 4061 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed 4062 Serial Links", RFC 1144, February 1990. 4063 4064 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 4065 RFC 1661, July 1994. 4066 4067 [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, 4068 July 1994. 4069 4070 [RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994. 4071 4072 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 4073 1700, October 1994. See also: 4074 http://www.iana.org/numbers.html 4075 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. 4076 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, 4077 August 1996. 4078 4079 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 4080 Protocol (CHAP)", RFC 1994, August 1996. 4081 4082 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 4083 and E. Lear, "Address Allocation for Private Internets", 4084 BCP 5, RFC 1918, February 1996. 4085 4086 4087 4088 4089 4090Townsley, et al. Standards Track [Page 73] 4091 4092RFC 2661 L2TP August 1999 4093 4094 4095 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4096 Requirement Levels", BCP 14, RFC 2119, March 1997. 4097 4098 [RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 4099 Authentication Dial In User Service (RADIUS)", RFC 2138, 4100 April 1997. 4101 4102 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 4103 Languages", BCP 18, RFC 2277, January 1998. 4104 4105 [RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two 4106 Forwarding (Protocol) L2F", RFC 2341, May 1998. 4107 4108 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 4109 Internet Protocol", RFC 2401, November 1998. 4110 4111 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 4112 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 4113 October 1998. 4114 4115 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. 4116 and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", 4117 RFC 2637, July 1999. 4118 4119 [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I The 4120 Protocols", Addison-Wesley Publishing Company, Inc., March 4121 1996, ISBN 0-201-63346-9 4122 412312.0 Acknowledgments 4124 4125 The basic concept for L2TP and many of its protocol constructs were 4126 adopted from L2F [RFC2341] and PPTP [PPTP]. Authors of these are A. 4127 Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein, 4128 J. Taarud, W. Little, and G. Zorn. 4129 4130 Dory Leifer made valuable refinements to the protocol definition of 4131 L2TP and contributed to the editing of this document. 4132 4133 Steve Cobb and Evan Caves redesigned the state machine tables. 4134 4135 Barney Wolff provided a great deal of design input on the endpoint 4136 authentication mechanism. 4137 4138 John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, 4139 Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and 4140 review at the 43rd IETF in Orlando, FL., which led to improvement of 4141 the overall readability and clarity of this document. 4142 4143 4144 4145 4146Townsley, et al. Standards Track [Page 74] 4147 4148RFC 2661 L2TP August 1999 4149 4150 415113.0 Authors' Addresses 4152 4153 Gurdeep Singh Pall 4154 Microsoft Corporation 4155 Redmond, WA 4156 4157 EMail: gurdeep@microsoft.com 4158 4159 4160 Bill Palter 4161 RedBack Networks, Inc 4162 1389 Moffett Park Drive 4163 Sunnyvale, CA 94089 4164 4165 EMail: palter@zev.net 4166 4167 4168 Allan Rubens 4169 Ascend Communications 4170 1701 Harbor Bay Parkway 4171 Alameda, CA 94502 4172 4173 EMail: acr@del.com 4174 4175 4176 W. Mark Townsley 4177 cisco Systems 4178 7025 Kit Creek Road 4179 PO Box 14987 4180 Research Triangle Park, NC 27709 4181 4182 EMail: townsley@cisco.com 4183 4184 4185 Andrew J. Valencia 4186 cisco Systems 4187 170 West Tasman Drive 4188 San Jose CA 95134-1706 4189 4190 EMail: vandys@cisco.com 4191 4192 4193 Glen Zorn 4194 Microsoft Corporation 4195 One Microsoft Way 4196 Redmond, WA 98052 4197 4198 EMail: gwz@acm.org 4199 4200 4201 4202Townsley, et al. Standards Track [Page 75] 4203 4204RFC 2661 L2TP August 1999 4205 4206 4207Appendix A: Control Channel Slow Start and Congestion Avoidance 4208 4209 Although each side has indicated the maximum size of its receive 4210 window, it is recommended that a slow start and congestion avoidance 4211 method be used to transmit control packets. The methods described 4212 here are based upon the TCP congestion avoidance algorithm as 4213 described in section 21.6 of TCP/IP Illustrated, Volume I, by W. 4214 Richard Stevens [STEVENS]. 4215 4216 Slow start and congestion avoidance make use of several variables. 4217 The congestion window (CWND) defines the number of packets a sender 4218 may send before waiting for an acknowledgment. The size of CWND 4219 expands and contracts as described below. Note however, that CWND is 4220 never allowed to exceed the size of the advertised window obtained 4221 from the Receive Window AVP (in the text below, it is assumed any 4222 increase will be limited by the Receive Window Size). The variable 4223 SSTHRESH determines when the sender switches from slow start to 4224 congestion avoidance. Slow start is used while CWND is less than 4225 SSHTRESH. 4226 4227 A sender starts out in the slow start phase. CWND is initialized to 4228 one packet, and SSHTRESH is initialized to the advertised window 4229 (obtained from the Receive Window AVP). The sender then transmits 4230 one packet and waits for its acknowledgement (either explicit or 4231 piggybacked). When the acknowledgement is received, the congestion 4232 window is incremented from one to two. During slow start, CWND is 4233 increased by one packet each time an ACK (explicit ZLB or 4234 piggybacked) is received. Increasing CWND by one on each ACK has the 4235 effect of doubling CWND with each round trip, resulting in an 4236 exponential increase. When the value of CWND reaches SSHTRESH, the 4237 slow start phase ends and the congestion avoidance phase begins. 4238 4239 During congestion avoidance, CWND expands more slowly. Specifically, 4240 it increases by 1/CWND for every new ACK received. That is, CWND is 4241 increased by one packet after CWND new ACKs have been received. 4242 Window expansion during the congestion avoidance phase is effectively 4243 linear, with CWND increasing by one packet each round trip. 4244 4245 When congestion occurs (indicated by the triggering of a 4246 retransmission) one half of the CWND is saved in SSTHRESH, and CWND 4247 is set to one. The sender then reenters the slow start phase. 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258Townsley, et al. Standards Track [Page 76] 4259 4260RFC 2661 L2TP August 1999 4261 4262 4263Appendix B: Control Message Examples 4264 4265B.1: Lock-step tunnel establishment 4266 4267 In this example, an LAC establishes a tunnel, with the exchange 4268 involving each side alternating in sending messages. This example 4269 shows the final acknowledgment explicitly sent within a ZLB ACK 4270 message. An alternative would be to piggyback the acknowledgement 4271 within a message sent as a reply to the ICRQ or OCRQ that will likely 4272 follow from the side that initiated the tunnel. 4273 4274 LAC or LNS LNS or LAC 4275 ---------- ---------- 4276 4277 SCCRQ -> 4278 Nr: 0, Ns: 0 4279 <- SCCRP 4280 Nr: 1, Ns: 0 4281 SCCCN -> 4282 Nr: 1, Ns: 1 4283 <- ZLB 4284 Nr: 2, Ns: 1 4285 4286B.2: Lost packet with retransmission 4287 4288 An existing tunnel has a new session requested by the LAC. The ICRP 4289 is lost and must be retransmitted by the LNS. Note that loss of the 4290 ICRP has two impacts: not only does it keep the upper level state 4291 machine from progressing, but it also keeps the LAC from seeing a 4292 timely lower level acknowledgment of its ICRQ. 4293 4294 LAC LNS 4295 --- --- 4296 4297 ICRQ -> 4298 Nr: 1, Ns: 2 4299 4300 (packet lost) <- ICRP 4301 Nr: 3, Ns: 1 4302 4303 (pause; LAC's timer started first, so fires first) 4304 4305 ICRQ -> 4306 Nr: 1, Ns: 2 4307 4308 (Realizing that it has already seen this packet, 4309 the LNS discards the packet and sends a ZLB) 4310 4311 4312 4313 4314Townsley, et al. Standards Track [Page 77] 4315 4316RFC 2661 L2TP August 1999 4317 4318 4319 <- ZLB 4320 Nr: 3, Ns: 2 4321 4322 (LNS's retransmit timer fires) 4323 4324 <- ICRP 4325 Nr: 3, Ns: 1 4326 ICCN -> 4327 Nr: 2, Ns: 3 4328 4329 <- ZLB 4330 Nr: 4, Ns: 2 4331 4332 4333 4334 4335 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370Townsley, et al. Standards Track [Page 78] 4371 4372RFC 2661 L2TP August 1999 4373 4374 4375Appendix C: Intellectual Property Notice 4376 4377 The IETF takes no position regarding the validity or scope of any 4378 intellectual property or other rights that might be claimed to 4379 pertain to the implementation or use of the technology described in 4380 this document or the extent to which any license under such rights 4381 might or might not be available; neither does it represent that it 4382 has made any effort to identify any such rights. Information on the 4383 IETF's procedures with respect to rights in standards-track and 4384 standards-related documentation can be found in BCP-11. Copies of 4385 claims of rights made available for publication and any assurances of 4386 licenses to be made available, or the result of an attempt made to 4387 obtain a general license or permission for the use of such 4388 proprietary rights by implementers or users of this specification can 4389 be obtained from the IETF Secretariat." 4390 4391 The IETF invites any interested party to bring to its attention any 4392 copyrights, patents or patent applications, or other proprietary 4393 rights which may cover technology that may be required to practice 4394 this standard. Please address the information to the IETF Executive 4395 Director. 4396 4397 The IETF has been notified of intellectual property rights claimed in 4398 regard to some or all of the specification contained in this 4399 document. For more information consult the online list of claimed 4400 rights. 4401 4402 4403 4404 4405 4406 4407 4408 4409 4410 4411 4412 4413 4414 4415 4416 4417 4418 4419 4420 4421 4422 4423 4424 4425 4426Townsley, et al. Standards Track [Page 79] 4427 4428RFC 2661 L2TP August 1999 4429 4430 4431Full Copyright Statement 4432 4433 Copyright (C) The Internet Society (1999). All Rights Reserved. 4434 4435 This document and translations of it may be copied and furnished to 4436 others, and derivative works that comment on or otherwise explain it 4437 or assist in its implementation may be prepared, copied, published 4438 and distributed, in whole or in part, without restriction of any 4439 kind, provided that the above copyright notice and this paragraph are 4440 included on all such copies and derivative works. However, this 4441 document itself may not be modified in any way, such as by removing 4442 the copyright notice or references to the Internet Society or other 4443 Internet organizations, except as needed for the purpose of 4444 developing Internet standards in which case the procedures for 4445 copyrights defined in the Internet Standards process must be 4446 followed, or as required to translate it into languages other than 4447 English. 4448 4449 The limited permissions granted above are perpetual and will not be 4450 revoked by the Internet Society or its successors or assigns. 4451 4452 This document and the information contained herein is provided on an 4453 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4454 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4455 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4456 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4457 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4458 4459Acknowledgement 4460 4461 Funding for the RFC Editor function is currently provided by the 4462 Internet Society. 4463 4464 4465 4466 4467 4468 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482Townsley, et al. Standards Track [Page 80] 4483 4484