idnits 2.17.00 (12 Aug 2021) /tmp/idnits26915/draft-ietf-l2tpext-l2tp-base-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 33 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([RFC2341], [RFC2637]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2832 has weird spacing: '...eptable cle...' == Line 2845 has weird spacing: '...eptable cle...' == Line 2848 has weird spacing: '...breaker re-qu...' == Line 2854 has weird spacing: '...ol-conn est...' == Line 2859 has weird spacing: '...eptable cle...' == (4 more instances...) -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The Mandatory (M) bit within the Message Type AVP has special meaning. Rather than an indication as to whether the AVP itself should be ignored if not recognized or malformed, it is an indication as to whether the control message itself should be ignored. If the M bit is set within the Message Type AVP and the Message Type is unknown to the implementation, the control connection MUST be cleared. If the M bit is not set, then the implementation may ignore an unknown message type. The M bit MUST be set to 1 for all message types defined in this document. This AVP MAY NOT be hidden (the H bit MUST be 0). The Length of this AVP is 8. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: OCRP is used to indicate that the LAC has been able to attempt the outbound call. The message returns any relevant parameters regarding the call attempt. Data MUST not be forwarded until the OCCN is received indicating that the call has been placed. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Assigned Cookie value MUST be selected in an unpredictable manner. However, the Cookie MUST not be regarded as packet-level authentication or security of any kind. It should be used for nothing more than simple configuration error detection and identification of misrouted packets. Since the Cookie is sent and advertised in the clear, it is by no means a true packet-level security measure, such as that offered by IPsec. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7280 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'DSS1' is defined on line 3364, but no explicit reference was found in the text == Unused Reference: 'RFC791' is defined on line 3373, but no explicit reference was found in the text == Unused Reference: 'RFC1144' is defined on line 3379, but no explicit reference was found in the text == Unused Reference: 'RFC1661' is defined on line 3382, but no explicit reference was found in the text == Unused Reference: 'RFC1662' is defined on line 3385, but no explicit reference was found in the text == Unused Reference: 'RFC1663' is defined on line 3388, but no explicit reference was found in the text == Unused Reference: 'RFC1990' is defined on line 3394, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 3401, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 3419, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS1' -- Possible downref: Non-RFC (?) normative reference: ref. 'KPS' ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2138 (Obsoleted by RFC 2865) ** Downref: Normative reference to an Historic RFC: RFC 2341 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2637 ** Downref: Normative reference to an Informational RFC: RFC 2764 ** Downref: Normative reference to an Informational RFC: RFC 2809 -- Possible downref: Non-RFC (?) normative reference: ref. 'STEVENS' == Outdated reference: draft-ietf-l2tpext-l2tp-atm has been published as RFC 3355 Summary: 13 errors (**), 0 flaws (~~), 21 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Lau 3 Internet-Draft M. Townsley 4 Category: Standards Track A. Valencia 5 G. Zorn 6 cisco Systems 7 I. Goyret 8 Lucent Technologies 9 G. Pall 10 Microsoft Corporation 11 A. Rubens 12 Nexthop 13 B. Palter 14 Redback Networks 15 June 2002 17 Layer Two Tunneling Protocol (Version 3) "L2TPv3" 19 Status of this Memo 21 This document is an Internet-Draft and is subject to all provisions 22 of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 42 Copyright (C) The Internet Society (2002). All Rights Reserved. 44 Abstract 46 This document describes the Layer Two Tunneling Protocol (L2TP). 47 L2TP tunnels Layer 2 packets across an intervening network in a way 48 that is as transparent as possible to both end users and 49 applications. 51 Acknowledgments 53 The basic concept for L2TP and many of its protocol constructs were 54 adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these 55 drafts are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, 56 W. Verthein, J. Taarud, W. Little, and G. Zorn. 58 Danny Mcpherson and Suhail Nanji published the first "L2TP Service 59 Type" draft which defined the use of L2TP for tunneling of multiple 60 L2 payload types. This step led to the eventual creation of this 61 document and the modularization of L2TP and PPP tunneling with L2TP. 63 The team for splitting RFC 2661 into this base document and the 64 companion PPP document consisted of Ignacio Goyret, Jed Lau, Bill 65 Palter, Mark Townsley, and Madhvi Verma. Skip Booth also provided 66 very helpful review and comment. 68 Stewart Bryant and Simon Barber provided input for the new L2TPv3 69 over IP header. 71 This document was based upon RFC 2661, for which a number of people 72 provided valuable input and effort: 74 John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, 75 Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and 76 review at the 43rd IETF in Orlando, FL, which led to improvement of 77 the overall readability and clarity of RFC 2661. 79 Thomas Narten provided a great deal of critical review and 80 formatting. He originally wrote the IANA Considerations section. 82 Dory Leifer made valuable refinements to the protocol definition of 83 L2TP and contributed to the editing of early drafts leading to RFC 84 2661. 86 Steve Cobb and Evan Caves redesigned the state machine tables. 88 Barney Wolff provided a great deal of design input on the endpoint 89 authentication mechanism. 91 Contents 93 Status of this Memo.......................................... 1 95 1. Introduction............................................. 5 96 1.1 Changes from RFC 2661................................ 5 97 1.2 Specification of Requirements........................ 6 98 1.3 Terminology.......................................... 6 100 2. Topology................................................. 9 102 3. Protocol Overview........................................ 11 103 3.1 Control Message Types................................ 12 104 3.2 L2TP Header Formats.................................. 13 105 3.2.1 L2TP Control Message Header..................... 13 106 3.2.2 L2TP Data Message............................... 14 107 3.3 Control Connection Management........................ 15 108 3.3.1 Control Connection Establishment................ 15 109 3.3.2 Control Connection Teardown..................... 15 110 3.4 Session Management................................... 16 111 3.4.1 Session Establishment for an Incoming Call...... 16 112 3.4.2 Session Establishment for an Outgoing Call...... 16 113 3.4.3 Session Teardown................................ 17 115 4. Protocol Operation....................................... 17 116 4.1 L2TP Over Specific Packet-Switched Networks (PSN).... 17 117 4.1.1 L2TP over IP.................................... 18 118 4.1.2 L2TP over UDP................................... 20 119 4.1.3 IP Fragmentation Issues......................... 22 120 4.2 Reliable Delivery of Control Messages................ 22 121 4.3 Control Connection Authentication.................... 24 122 4.4 Keepalive (Hello).................................... 25 123 4.5 Forwarding Session Data Frames....................... 25 124 4.6 Default PW Control Encapsulation..................... 26 125 4.6.1 Sequencing Data Packets......................... 27 126 4.7 L2TPv2/v3 Interoperability and Migration............. 27 127 4.7.1 L2TPv3 over IP.................................. 28 128 4.7.2 L2TPv3 over UDP................................. 28 129 4.7.3 Automatic L2TPv2 Fallback....................... 28 131 5. Control Message Attribute Value Pairs.................... 29 132 5.1 AVP Format........................................... 29 133 5.2 Mandatory AVPs....................................... 30 134 5.3 Hiding of AVP Attribute Values....................... 31 135 5.4 AVP Summary.......................................... 33 136 5.4.1 AVPs Applicable to All Control Messages......... 33 137 5.4.2 Result and Error Codes.......................... 35 138 5.4.3 Control Connection Management AVPs.............. 37 139 5.4.4 Session Management AVPs......................... 42 140 5.4.5 Circuit Status AVPs............................. 50 142 6. Control Connection Protocol Specification................ 52 143 6.1 Start-Control-Connection-Request (SCCRQ)............. 52 144 6.2 Start-Control-Connection-Reply (SCCRP)............... 52 145 6.3 Start-Control-Connection-Connected (SCCCN)........... 53 146 6.4 Stop-Control-Connection-Notification (StopCCN)....... 53 147 6.5 Hello (HELLO)........................................ 54 148 6.6 Incoming-Call-Request (ICRQ)......................... 54 149 6.7 Incoming-Call-Reply (ICRP)........................... 55 150 6.8 Incoming-Call-Connected (ICCN)....................... 55 151 6.9 Outgoing-Call-Request (OCRQ)......................... 56 152 6.10 Outgoing-Call-Reply (OCRP).......................... 57 153 6.11 Outgoing-Call-Connected (OCCN)...................... 57 154 6.12 Call-Disconnect-Notify (CDN)........................ 58 155 6.13 WAN-Error-Notify (WEN).............................. 58 156 6.14 Set-Link-Info (SLI)................................. 58 158 7. Control Connection State Machines........................ 59 159 7.1 Malformed Control Messages........................... 59 160 7.2 Timing Considerations................................ 60 161 7.3 Control Connection States............................ 60 162 7.4 Incoming Calls....................................... 62 163 7.4.1 ICRQ Sender States.............................. 63 164 7.4.2 ICRQ Recipient States........................... 64 165 7.5 Outgoing Calls....................................... 65 166 7.5.1 OCRQ Sender States.............................. 65 167 7.5.2 OCRQ Recipient (LAC) States..................... 67 168 7.6 Termination of a Control Connection.................. 68 170 8. Security Considerations.................................. 68 171 8.1 Control Connection Endpoint Security................. 68 172 8.2 Packet-Level Security................................ 69 173 8.3 End-to-End Security.................................. 69 174 8.4 L2TP and IPsec....................................... 69 175 8.5 Impact of L2TPv3 Features on RFC 3193................ 70 177 9. IANA Considerations...................................... 70 178 9.1 AVP Attributes....................................... 70 179 9.2 Message Type AVP Values.............................. 71 180 9.3 Result Code AVP Values............................... 71 181 9.3.1 Result Code Field Values........................ 71 182 9.3.2 Error Code Field Values......................... 71 183 9.4 AVP Header Bits...................................... 71 184 9.5 L2TP Control Message Header Bits..................... 71 186 10. References.............................................. 72 187 11. Editors' Addresses...................................... 74 189 Appendix A: Control Slow Start and Congestion Avoidance...... 74 191 Appendix B: Control Message Examples......................... 75 193 Appendix C: Intellectual Property Notice..................... 77 195 Appendix D: Full Copyright Statement......................... 77 197 1. Introduction 199 The Layer Two Tunneling Protocol (L2TP) provides a dynamic tunneling 200 mechanism for multiple Layer 2 (L2) circuits across a packet-oriented 201 data network. L2TP, as originally defined in RFC 2661, is a standard 202 method for tunneling PPP sessions. L2TP has since been adopted for 203 tunneling a number of other L2 protocols. In order to provide 204 greater modularity, this document describes the base L2TP protocol, 205 independent of the L2 payload that is being tunneled. 207 The base L2TP protocol consists of (1) the control protocol for 208 dynamic creation, maintenance, and teardown of L2TP sessions, and (2) 209 the L2TP data encapsulation to multiplex and demultiplex L2 data 210 streams between two L2TP peers. 212 1.1 Changes from RFC 2661 214 Most of the protocol constructs described in this document are 215 carried over from RFC 2661. Changes include clarifications based on 216 years of interoperability and deployment experience as well as 217 modifications to either improve protocol operation or provide a 218 clearer separation from PPP. The intent of these modifications is to 219 achieve a healthy balance between code, interoperability experience 220 with RFC 2661, and a thoughtful and directed evolution of the 221 protocol as it is applied to new tasks. 223 When the designation between L2TPv2 and L2TPv3 is necessary, L2TP as 224 defined in RFC 2661 will be referred to as "L2TPv2", corresponding to 225 the value in the Version field of an L2TP control message header. 226 (L2F is defined as "version 1".) At times, L2TP as defined in this 227 document will be referred to as "L2TPv3". Otherwise, the acronym 228 "L2TP" will refer to L2TPv3 or L2TP in general. 230 Notable differences between L2TPv2 and L2TPv3 include the following: 231 - Separation of all PPP-related AVPs, references, etc., including a 232 portion of the L2TP data header that was specific to the needs of 233 PPP. The PPP-specific constructs are described in a companion 234 document. 236 - Transition from a 16-bit Session ID and Tunnel ID to a 32-bit 237 Session ID and Control Connection ID, respectively. 239 Details of these changes and a recommendation for transitioning to 240 L2TPv3 may be found in Section 4.7. 242 1.2 Specification of Requirements 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 246 document are to be interpreted as described in [RFC2119]. 248 1.3 Terminology 250 Attribute Value Pair (AVP) 252 The variable-length concatenation of a unique Attribute 253 (represented by an integer) and a Value containing the actual 254 value identified by the attribute. Multiple AVPs make up control 255 messages, which are used in the establishment, maintenance, and 256 teardown of control connections. This construct is known as the 257 Type-Length-Value (TLV) in some specifications. (See also: 258 Control Connection, Control Message.) 260 Call (Circuit Up) 262 The action of transitioning a circuit on an LAC to an "up" or 263 "active" state. A call may be dynamically established through 264 signaling properties (e.g. an incoming or outgoing call through 265 the PSTN) or statically configured (e.g. provisioning a VC on an 266 interface). A call is defined by its properties (e.g. type of 267 call, called number, etc.) and its data traffic. (See also: 268 Circuit, Session, Incoming Call, Outgoing Call, Outgoing Call 269 Request.) 271 CHAP 273 Challenge Handshake Authentication Protocol [RFC1994], a point-to- 274 point cryptographic challenge/response authentication protocol in 275 which the cleartext password is not passed over the line. 277 Circuit 279 A general term identifying any one of a wide range of L2 280 connections. A circuit may be virtual in nature (e.g. an ATM PVC 281 or an L2TP session), or it may have direct correlation to a 282 physical layer (e.g. an RS-232 serial line). Circuits may be 283 statically configured with a relatively long-lived uptime, or 284 dynamically established with some type of control channel 285 governing the establishment, maintenance, and teardown of the 286 circuit. For the purposes of this document, a statically 287 configured circuit is considered to be largely equivalent to a 288 simple dynamic circuit. (See also: Call, Remote System.) 290 Client 292 (See Remote System.) 294 Control Connection 296 An L2TP control connection is a reliable control channel that is 297 used to establish, maintain, and release individual L2TP sessions 298 as well as the control channel itself. (See also: Control 299 Message, Data Channel.) 301 Control Message 303 An L2TP message used by the control connection. (See also: 304 Control Connection.) 306 Data Message 308 Message used by the data channel. (See also: Data Channel.) 310 Data Channel 312 The channel of L2TP-encapsulated L2 traffic that passes between 313 two LCCEs, utilizing a specific data encapsulation method. L2TP 314 defines one base encapsulation method for L2 traffic, although 315 others may be used as well. (See also: Control Connection, Data 316 Message.) 318 Dominant LCCE 320 The LCCE that either solely initiated establishment of a control 321 connection or won the tie-breaker during control connection 322 establishment. (See also: LCCE, Section 5.4.3.) 324 Incoming Call 326 The action of receiving a call (circuit up event) on an LAC. The 327 call may have been placed by a remote system (e.g. a phone call 328 over a PSTN), or it may have been triggered by a local event (e.g. 329 interesting traffic routed to a virtual interface). An incoming 330 call that needs to be tunneled (as determined by the LAC) results 331 in the generation of an L2TP ICRQ message. (See also: Call, 332 Outgoing Call, Outgoing Call Request.) 334 L2TP Access Concentrator (LAC) 336 An LCCE that tunnels a circuit (either physically connected or 337 logically connected, as via another L2TP session) to another 338 location using L2TP, without performing any native L2 packet 339 processing on the circuit. The LAC may tunnel to either an LNS or 340 another LAC. (See also: LCCE, LNS.) 342 L2TP Control Connection Endpoint (LCCE) 344 One end of an L2TP control connection, either an LAC or an LNS. 345 (See also: LAC, LNS.) 347 L2TP Network Server (LNS) 349 An LCCE that logically terminates a tunneled circuit locally and 350 that processes the tunneled traffic as though the circuit were 351 physically connected to the device. The LNS may tunnel to either 352 an LAC or another LNS. (See also: LCCE, LAC.) 354 Outgoing Call 356 The action of placing a call on an LAC, typically in response to 357 policy directed by the peer in an Outgoing Call Request message. 358 (See also: Call, Incoming Call, Outgoing Call Request.) 360 Outgoing Call Request 362 A request sent to an LAC to place an outgoing call. The request 363 contains specific information for the LAC in placing the call, 364 information that is typically not known a priori by the LAC. (See 365 also: Call, Incoming Call, Outgoing Call.) 367 Packet-Switched Network (PSN) 369 A network layer that uses packet-switching technology for data 370 delivery. This layer is principally IP. Other examples include 371 MPLS, FR, and ATM. 373 Peer 375 When used in context with L2TP, Peer refers to the far end of an 376 L2TP control connection (i.e. the far LCCE). An LAC's peer may be 377 either an LNS or another LAC. Similarly, an LNS's peer may be 378 either an LAC or another LNS. (See also: LAC, LCCE, LNS.) 380 Pseudowire (PW) 382 An emulated circuit as it traverses a PSN. There is one 383 Pseudowire per L2TP Session. (See also: Packet-Switched Network, 384 Session.) 386 Pseudowire Type 388 The payload type being carried within an L2TP session. Examples 389 include PPP, Ethernet, and Frame Relay. (See also: Session.) 391 Remote System 393 An end-system or router connected by a circuit to an LAC. 395 Session 397 An L2TP session is created by a particular L2TP control connection 398 between two LCCEs when a circuit is successfully established. The 399 circuit may either pass through (LAC) or terminate locally (LNS) 400 on the LCCEs, which maintain state for the circuit. There is a 401 one-to-one relationship between established L2TP sessions and 402 their associated circuits. (See also: Circuit, LAC, LCCE, LNS.) 404 Zero-Length Body (ZLB) Message 406 A control message with only an L2TP header. ZLB messages are used 407 for explicitly acknowledging packets on the reliable control 408 channel. (See also: Control Message.) 410 2. Topology 412 L2TP operates between two L2TP Control Connection Endpoints (LCCEs), 413 tunneling circuit traffic across a packet network. An L2TP Network 414 Server (LNS) is an LCCE that decapsulates tunneled L2 traffic and 415 directs it as incoming data towards a virtual L2 interface. In 416 contrast, an L2TP Access Concentrator (LAC) is an LCCE that merely 417 forwards tunneled traffic directly to a circuit (which may even be 418 another L2TP session). 420 There are three predominant tunneling models in which L2TP operates: 421 LAC-LNS (or vice versa), LAC-LAC, and LNS-LNS. These models are 422 diagrammed below. (Dotted lines designate network connections. 423 Solid lines designate circuit connections.) 424 Figure 2.0: L2TP Reference Models 426 (a) LAC-LNS Reference Model: On one side, the LAC receives traffic 427 from an L2 circuit, which it forwards via L2TP across an IP or other 428 packet-based network. On the other side, an LNS logically terminates 429 the L2 circuit locally and routes traffic (at Layer 3) to the home 430 network. The action of session establishment may be driven by the 431 LAC (perhaps as an incoming call) or the LNS (perhaps as an outgoing 432 call). This model typically has, but does not require, a clear 433 initiator and responder. 435 +-----+ L2 +-----+ +-----+ 436 | |------| LAC |....[packet network]....| LNS |...[home network] 437 +-----+ +-----+ +-----+ 438 remote 439 system 440 |<-- emulated service -->| 441 |<----------- L2 service ------------>| 443 (b) LAC-LAC Reference Model: In this model, both LCCEs are LACs. 444 Each LAC forwards circuit traffic from the remote system to the peer 445 LAC using L2TP, and vice versa. A LAC does not perform any native 446 handling of the tunneled L2 frame, and thus, does not utilize a 447 virtual L2 interface. Rather, a LAC acts as a simple cross-connect 448 between a circuit and an L2TP session. This model typically involves 449 symmetric establishment; that is, either side of the connection may 450 initiate a session at any time (or perhaps simultaneously). 452 +-----+ L2 +-----+ +-----+ L2 +-----+ 453 | |------| LAC |...[packet network]...| LAC |------| | 454 +-----+ +-----+ +-----+ +-----+ 455 remote remote 456 system system 457 |<- emulated service ->| 458 |<----------------- L2 service ----------------->| 460 (c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs. 461 Rather than forwarding traffic directly over a circuit, each LNS 462 logically terminates the tunneled L2TP session locally. In this 463 manner, both sides have virtual interfaces associated with each L2TP 464 session. A user-level, traffic-generated, or signaled event 465 typically drives session establishment from one side of the tunnel. 466 Also known as "voluntary tunneling" (see [RFC2809]). 468 +-----+ +-----+ 469 [home network]...| LNS |...[packet network]...| LNS |...[home network] 470 +-----+ +-----+ 471 |<- emulated service ->| 472 |<---- L2 service ---->| 474 Note: If an LNS initiates session establishment due to an event 475 (generally user-driven), the LNS is sometimes referred to as a "LAC 476 Client" as defined in [RFC2661]. 478 3. Protocol Overview 480 L2TP utilizes two types of messages, control messages and data 481 messages. Control messages are used in the establishment, 482 maintenance, and clearing of control connections and sessions. These 483 messages utilize a reliable control channel within L2TP to guarantee 484 delivery (see Section 4.2 for details). Data messages are used to 485 encapsulate the L2 traffic being carried over the L2TP session. 486 Unlike control messages, data messages are not retransmitted when 487 packet loss occurs. 489 While both the L2TP control channel and the L2TP data channel are 490 defined strictly in this document, the L2TP data channel MAY be 491 substituted with a different L2 tunneling encapsulation whose format 492 can negotiated by the L2TP control connection. Furthermore, the L2TP 493 data channel MAY be used without the control channel, if so desired. 494 However, it is strongly recommended that such practice be limited to 495 relatively small-scale deployments or deployments in which some other 496 form of automatic control information distribution is employed. 498 Figure 3.0: L2TPv3 Structure 500 +-------------------+ 501 | L2 Frames | 502 +-------------------+ +-----------------------+ 503 | L2TP Data Messages| | L2TP Control Messages | 504 +-------------------+ +-----------------------+ 505 | L2TP Data Channel | | L2TP Control Channel | 506 | (unreliable) | | (reliable) | 507 +-------------------+----+-----------------------+ 508 | Packet-Switched Network (IP, FR, MPLS, etc.) | 509 +------------------------------------------------+ 511 Figure 3.0 depicts the relationship of control messages and data 512 messages over the L2TP control and data channels, respectively. Data 513 messages are passed over an unreliable data channel, encapsulated by 514 an L2TP header, and sent over a Packet-Switched Network (PSN) such as 515 IP, UDP, Frame Relay, ATM, MPLS, etc. Control messages are sent over 516 a reliable L2TP control channel, which operates over the same PSN. 518 The necessary setup for tunneling a session with L2TP consists of two 519 steps: (1) Establishing the control connection, if required, and (2) 520 establishing a session as triggered by an incoming call or outgoing 521 call. An L2TP session MUST be established before L2TP can begin to 522 forward session frames. Multiple sessions may be bound to a single 523 control connection, and multiple control connections may exist 524 between the same two LCCEs. 526 3.1 Control Message Types 528 The Message Type AVP (see Section 5.4.1) defines the specific type of 529 control message being sent. 531 This document defines the following control message types (see 532 Sections 6.1 through 6.13 for details on the construction and use of 533 each message): 535 Control Connection Management 537 0 (reserved) 538 1 (SCCRQ) Start-Control-Connection-Request 539 2 (SCCRP) Start-Control-Connection-Reply 540 3 (SCCCN) Start-Control-Connection-Connected 541 4 (StopCCN) Stop-Control-Connection-Notification 542 5 (reserved) 543 6 (HELLO) Hello 545 Call Management 547 7 (OCRQ) Outgoing-Call-Request 548 8 (OCRP) Outgoing-Call-Reply 549 9 (OCCN) Outgoing-Call-Connected 550 10 (ICRQ) Incoming-Call-Request 551 11 (ICRP) Incoming-Call-Reply 552 12 (ICCN) Incoming-Call-Connected 553 13 (reserved) 554 14 (CDN) Call-Disconnect-Notify 556 Error Reporting 558 15 (WEN) WAN-Error-Notify 560 Link Status Change Reporting 562 16 (SLI) Set-Link-Info 564 3.2 L2TP Header Formats 566 This section defines header formats for L2TP control messages and 567 L2TP data messages. All values are placed into their respective 568 fields and sent in network order (high-order octets first). 570 3.2.1 L2TP Control Message Header 572 The L2TP control message header provides information for the reliable 573 transport of messages that govern the establishment, maintenance, and 574 teardown of L2TP sessions. By default, control messages are sent 575 over the underlying media in-band with L2TP data messages. As such, 576 L2TP also includes a default method (borrowing from RFC 2661 by 577 utilizing the high bit of the first octet in the L2TP header) that 578 may be used to distinguish L2TP control messages from L2TP data 579 messages. Other methods for distinguishing control and data messages 580 MAY be utilized for specific media (e.g. L2TP over IP, as defined in 581 Section 4.1.1). 583 The L2TP control message header is formatted as follows: 585 Figure 3.2.1: L2TP Control Message Header 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 |T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Control Connection ID | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Ns | Nr | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 The T bit MUST be set to 1, indicating that this is a control 598 message. 600 The L and S bits MUST be set to 1, indicating that the Length field 601 and sequence numbers are present. 603 The x bits are reserved for future extensions. All reserved bits 604 MUST be set to 0 on outgoing messages and ignored on incoming 605 messages. 607 The Ver field indicates the version of the L2TP control message 608 header described in this document. On sending, this field MUST be 609 set to 3 for all messages (unless operating in an environment with 610 L2TPv2 [RFC2661] and/or L2F [RFC2341], see Section 4.1 for details). 612 The Length field indicates the total length of the message in octets, 613 always calculated from the start of the control message header itself 614 (beginning with the T bit). 616 The Control Connection ID field contains the identifier for the 617 control connection. L2TP control connections are named by 618 identifiers that have local significance only. That is, the same 619 control connection will be given unique Control Connection IDs by 620 each LCCE from within each endpoint's own Control Connection ID 621 number space. As such, the Control Connection ID in each message is 622 that of the intended recipient, not the sender. Non-zero Control 623 Connection IDs are selected and exchanged as Assigned Control 624 Connection ID AVPs during the creation of a control connection. 626 Ns indicates the sequence number for this control message, beginning 627 at zero and incrementing by one (modulo 2**16) for each message sent. 628 See Section 4.2 for more information on using this field. 630 Nr indicates the sequence number expected in the next control message 631 to be received. Thus, Nr is set to the Ns of the last in-order 632 message received plus one (modulo 2**16). See Section 4.2 for more 633 information on using this field. 635 3.2.2 L2TP Data Message 637 In general, an L2TP data message consists of a (1) Session Header, 638 (2) an optional PW Control Encapsulation, and (3) the Tunneled L2 639 Frame, as depicted below. 641 Figure 3.2.2: L2TP Data Message 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | L2TP Session Header | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | PW Control Encapsulation | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Tunneled Frame | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 The L2TP Session Header is specific to the PSN over which the L2TP 652 traffic is delivered. The Session Header SHOULD provide (1) a method 653 of distinguishing traffic among multiple L2TP data sessions and (2) a 654 method of distinguishing data messages from control messages 655 (assuming the messages are received in-band). 657 Each type of PSN MUST define its own session header, clearly 658 identifying the format of the header and parameters necessary to 659 setup the session. Section 4.1 defines two session headers, one for 660 transport over UDP and one for transport over IP. 662 The PW Control Encapsulation is an intermediary layer between the 663 L2TP session header and the start of the tunneled frame. It SHOULD 664 contain control fields that are used to facilitate the tunneling of 665 each frames (e.g. sequence numbers). The default PW control 666 encapsulation for L2TPv3 is defined in Section 4.6. 668 The Tunneled Frame consists of PW data traffic, including any 669 necessary L2 framing as defined in the payload-specific companion 670 documents. 672 3.3 Control Connection Management 674 The L2TP Control Connection handles dynamic establishment, teardown, 675 and maintenance of the L2TP sessions and of the control connection 676 itself. The reliable delivery of control messages is described in 677 Section 4.2. 679 This section describes the typical control connection establishment 680 and teardown exchanges. It is important to note that, in the 681 diagrams that follow, the reliable control message delivery mechanism 682 exists independently of the L2TP state machine. For instance, ZLB 683 ACKs may be sent after any of the control messages indicated in the 684 exchanges below if an acknowledgment is not piggybacked on a later 685 control message. 687 3.3.1 Control Connection Establishment 689 Establishment of the control connection involves an exchange of AVPs 690 that identifies the peer and its capabilities. 692 A three-message exchange is used to establish the control connection. 693 The following is a typical message exchange: 695 LCCE A LCCE B 696 ------ ------ 697 SCCRQ -> 698 <- SCCRP 699 SCCCN -> 701 3.3.2 Control Connection Teardown 703 Control connection teardown may be initiated by either LCCE and is 704 accomplished by sending a single StopCCN control message. As part of 705 the reliable control message delivery mechanism, the recipient of a 706 StopCCN MUST send a ZLB ACK to acknowledge receipt of the message and 707 maintain enough control connection state to properly accept StopCCN 708 retransmissions over at least a full retransmission cycle (in case 709 the ZLB ACK is lost). The recommended time for a full retransmission 710 cycle is at least 31 seconds (see Section 4.2). The following is an 711 example of a typical control message exchange: 713 LCCE A LCCE B 714 ------ ------ 715 StopCCN -> 716 (Clean up) 718 (Wait) 719 (Clean up) 721 An implementation may shut down an entire control connection and all 722 sessions associated with the control connection by sending the 723 StopCCN. Thus, it is not necessary to clear each session 724 individually when tearing down the whole control connection. 726 3.4 Session Management 728 After successful control connection establishment, individual 729 sessions may be created. Each session corresponds to a single data 730 stream between the two LCCEs. This section describes the typical 731 call establishment and teardown exchanges. 733 3.4.1 Session Establishment for an Incoming Call 735 A three-message exchange is used to establish the session. The 736 following is a typical sequence of events: 738 LCCE A LCCE B 739 ------ ------ 740 (Call 741 Detected) 743 ICRQ -> 744 <- ICRP 745 ICCN -> 747 3.4.2 Session Establishment for an Outgoing Call 749 A three-message exchange is used to set up the session. The 750 following is a typical sequence of events: 752 LCCE A LCCE B 753 ------ ------ 754 <- OCRQ 755 OCRP -> 757 (Perform 758 Call 759 Operation) 761 OCCN -> 763 3.4.3 Session Teardown 765 Session teardown may be initiated by either the LAC or LNS and is 766 accomplished by sending a CDN control message. After the last 767 session is cleared, the control connection MAY be torn down as well 768 (and typically is). The following is an example of a typical control 769 message exchange: 771 LCCE A LCCE B 772 ------ ------ 773 CDN -> 774 (Clean up) 776 (Clean up) 778 4. Protocol Operation 780 This section addresses various operational issues in both the control 781 connection and data channel of L2TP. 783 4.1 L2TP Over Specific Packet-Switched Networks (PSN) 785 L2TP is designed to allow operation over a variety of PSNs. The L2TP 786 Session Header encapsulation MAY vary for a given PSN. 788 This document describes the standard method for operation of L2TP 789 over IPv4 networks. There are two modes described, L2TP over IP 790 (Section 4.1.1) and L2TP over UDP (Section 4.1.2). L2TPv3 791 implementations MUST support L2TP over IP and SHOULD support L2TP 792 over UDP for better NAT and FW traversal, integration with IPsec 793 [RFC3193], and easier migration from L2TPv2. 795 L2TP over other PSNs may be defined, but the specifics are outside 796 the scope of this document. Examples of L2TPv2 over other PSNs 797 include [RFC3070] and [L2TPAAL5]. 799 The following field definitions are defined for use in all L2TP 800 Session Header encapsulations. 802 Session ID 804 A 32-bit field containing a non-zero identifier for a session. 805 L2TP sessions are named by identifiers that have local 806 significance only. That is, the same logical session will be 807 given different Session IDs by each end of the control connection 808 for the life of the session. When the L2TP control connection is 809 used for session establishment, Session IDs are selected and 810 exchanged as Local Session ID AVPs during the creation of a 811 session. 813 Cookie 815 The optional Cookie field contains a variable length (maximum 64 816 bits), longword-aligned value used to check the association of a 817 received data message with the session identified by the Session 818 ID. The Cookie MUST be configured with a random value utilizing 819 all bits in the field. The Cookie provides an additional level of 820 guarantee, beyond the Session ID lookup, that a data message has 821 been directed to the proper session. A well-chosen Cookie may 822 prevent inadvertent misdirection of stray packets with recently 823 reused Session IDs, Session IDs subject to packet corruption, etc. 825 When the L2TP control connection is used for session 826 establishment, random Cookie values are selected and exchanged as 827 Assigned Cookie AVPs during the creation of a session. The 828 maximum size of the Cookie field is 64 bits. 830 4.1.1 L2TP over IP 832 L2TP over IP utilizes the IANA assigned IP protocol ID 115. 834 4.1.1.1 L2TP over IP Session Header 836 Unlike L2TP over UDP, the L2TPv3 session header over IP is free of 837 any restrictions imposed by coexistence with L2TPv2 and L2F. As 838 such, the header format has been redesigned to optimize packet 839 processing. The following session header format is utilized when 840 operating L2TPv3 over IP: 842 Figure 4.1.1.1: L2TPv3 over IP Session Header 844 0 1 2 3 845 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 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Session ID | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Cookie (optional, maximum 64 bits)... 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 The Session ID and Cookie fields are as defined in Section 4.1. The 855 Session ID of zero is reserved for use by L2TP control messages (see 856 Section 4.1.1.2). 858 It should be noted that the absence of the Version and Flags fields, 859 which are present in L2TP over UDP, prevents straightforward version 860 extensibility for data messages. However, given the freedom of 861 setting the first 32 bits in the data message header (i.e. the 862 Session ID field), an acceptable workaround to this limitation can be 863 devised if an extension to the demultiplexing capabilities of L2TP is 864 ever in need of further revision. In contrast, the control message 865 header still retains all version checking ability. 867 4.1.1.2 L2TP Control and Data Traffic over IP 869 As shown in Section 4.1.1.1, there are no Version and Flags fields in 870 the L2TP Session Header over IP. Specifically, the T bit does not 871 exist to distinguish control packets and data packets. Instead, all 872 control packets are sent over the reserved session ID of 0. It is 873 presumed that this method is more efficient -- both in header size 874 for data packets and in processing speed for distinguishing control 875 messages -- than checking for the presence of certain bits. 877 The entire control message header over IP, including the zero session 878 ID, appears as follows: 880 Figure 4.1.1.2: L2TPv3 over IP Control Message Header 882 0 1 2 3 883 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | (32 bits of zeros) | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 |T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Control Connection ID | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Ns | Nr | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 Named fields are as defined in Section 3.2.1. Note that the Length 895 field is still calculated from the beginning of the control message 896 header, beginning with the T bit. It does NOT include the "(32 bits 897 of zeros)" depicted above. 899 4.1.2 L2TP over UDP 901 L2TPv3 over UDP must consider other L2 tunneling protocols that may 902 be operating in the same environment, including L2TPv2 [RFC2661] and 903 L2F [RFC2341]. 905 While there are efficiencies gained by running L2TP directly over IP, 906 there are possible side effects as well. For instance, L2TP over IP 907 is not as NAT-friendly as L2TP over UDP. Also, control messages 908 transmitted over IP are not protected by a network-layer checksum as 909 they are with UDP. 911 4.1.2.1 L2TP over UDP Session Header 913 The following session header format is utilized when operating L2TPv3 914 over UDP: 916 Figure 4.1.2.1: L2TPv3 over UDP Session Header 918 0 1 2 3 919 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 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 |T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Session ID | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Cookie (optional, maximum 64 bits)... 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 The T bit MUST be set to 0, indicating that this is a data message. 932 The x bits and Reserved field are reserved for future extensions. 933 All reserved values MUST be set to 0 on outgoing messages and ignored 934 on incoming messages. 936 The Ver field MUST be set to 3, indicating an L2TPv3 message. 938 The Session ID and Cookie fields are as defined in Section 4.1. 940 4.1.2.2 L2TP over UDP Port Selection 942 L2TPv3 utilizes the same UDP port selection method as defined in 943 L2TPv2 [RFC2661]. 945 When negotiating a control connection over UDP, control messages 946 first must be sent as UDP datagrams using the registered UDP port 947 1701 [RFC1700]. The initiator of an L2TP control connection picks an 948 available source UDP port (which may or may not be 1701), and sends 949 to the desired destination address at port 1701. The recipient picks 950 a free port on its own system (which may or may not be 1701) and 951 sends its reply to the initiator's UDP port and address, setting its 952 own source port to the free port it found. 954 Any subsequent traffic associated with this control connection 955 (either control traffic or data traffic from a session established 956 through this control connection) must use these same UDP ports. This 957 method has some inefficiencies with regard to packet processing. 958 However, it is the most NAT-friendly method since there is only one 959 entry in the NAT table to be kept valid, and the control connection 960 can provide a keepalive to ensure that the NAT entry remains valid. 961 Also, firewalls can be configured to pass all control and data 962 traffic with a single entry rather than separate entries for control 963 and for data. 965 It has been suggested that having the recipient choose an arbitrary 966 source port (as opposed to using the destination port in the packet 967 initiating the control connection, i.e., 1701) may make it more 968 difficult for L2TP to traverse some NAT devices. Implementations 969 should consider the potential implication of this capability before 970 choosing an arbitrary source port. Any NAT device that can pass TFTP 971 traffic should be able to pass L2TP UDP traffic since both protocols 972 employ similar policies with regard to UDP port selection. 974 4.1.2.3 UDP Checksum 976 UDP checksums MUST be enabled for control messages and MAY be enabled 977 for data messages. It should be noted, however, that enabling 978 checksums on data packets may significantly increase packet 979 processing burden. 981 4.1.3 IP Fragmentation Issues 983 IP fragmentation may occur as the L2TP packet travels over the IP 984 substrate. L2TP makes no special efforts defined in this document to 985 optimize this. 987 4.2 Reliable Delivery of Control Messages 989 L2TP provides a lower level reliable delivery service for all control 990 messages. The Nr and Ns fields of the control message header (see 991 Section 3.2.1) belong to this delivery mechanism. The upper level 992 functions of L2TP are not concerned with retransmission or ordering 993 of control messages. The reliable control messaging mechanism is a 994 sliding window mechanism that provides control message retransmission 995 and congestion control. Each peer maintains separate sequence number 996 state for each control connection. 998 The message sequence number, Ns, begins at 0. Each subsequent 999 message is sent with the next increment of the sequence number. The 1000 sequence number is thus a free-running counter represented modulo 1001 65536. The sequence number in the header of a received message is 1002 considered less than or equal to the last received number if its 1003 value lies in the range of the last received number and the preceding 1004 32767 values, inclusive. For example, if the last received sequence 1005 number was 15, then messages with sequence numbers 0 through 15, as 1006 well as 32784 through 65535, would be considered less than or equal. 1007 Such a message would be considered a duplicate of a message already 1008 received and ignored from processing. However, in order to ensure 1009 that all messages are acknowledged properly (particularly in the case 1010 of a lost ZLB ACK message), receipt of duplicate messages MUST be 1011 acknowledged by the reliable delivery mechanism. This acknowledgment 1012 may either piggybacked on a message in queue or sent explicitly via a 1013 ZLB ACK. 1015 All control messages take up one slot in the control message sequence 1016 number space, except the ZLB acknowledgment. Thus, Ns is not 1017 incremented after a ZLB message is sent. 1019 The last received message number, Nr, is used to acknowledge messages 1020 received by an L2TP peer. It contains the sequence number of the 1021 message the peer expects to receive next (e.g. the last Ns of a non- 1022 ZLB message received plus 1, modulo 65536). While the Nr in a 1023 received ZLB is used to flush messages from the local retransmit 1024 queue (see below), the Nr of the next message sent is not updated by 1025 the Ns of the ZLB. As a precaution, Nr should be sanity-checked 1026 before flushing the retransmit queue. For instance, if the Nr 1027 received in a control message is greater than the last Ns sent plus 1 1028 modulo 65536, the control message is clearly invalid. 1030 The reliable delivery mechanism at a receiving peer is responsible 1031 for making sure that control messages are delivered in order and 1032 without duplication to the upper level. Messages arriving out of 1033 order may be queued for in-order delivery when the missing messages 1034 are received. Alternatively, they may be discarded, thus requiring a 1035 retransmission by the peer. When dropping out of order control 1036 packets, Nr MAY be updated before the packet is discarded. 1038 Each control connection maintains a queue of control messages to be 1039 transmitted to its peer. The message at the front of the queue is 1040 sent with a given Ns value and is held until a control message 1041 arrives from the peer in which the Nr field indicates receipt of this 1042 message. After a period of time (a recommended default is 1 second) 1043 passes without acknowledgment, the message is retransmitted. The 1044 retransmitted message contains the same Ns value, but the Nr value 1045 MUST be updated with the sequence number of the next expected 1046 message. 1048 Each subsequent retransmission of a message MUST employ an 1049 exponential backoff interval. Thus, if the first retransmission 1050 occurred after 1 second, the next retransmission should occur after 2 1051 seconds has elapsed, then 4 seconds, etc. An implementation MAY 1052 place a cap upon the maximum interval between retransmissions. This 1053 cap MUST be no less than 8 seconds per retransmission. If no peer 1054 response is detected after several retransmissions (a recommended 1055 default is 5, but SHOULD be configurable), the control connection and 1056 all associated sessions MUST be cleared. 1058 When a control connection is being shut down for reasons other than 1059 loss of connectivity, the state and reliable delivery mechanisms MUST 1060 be maintained and operated for the full retransmission interval after 1061 the final message exchange has occurred. 1063 A sliding window mechanism is used for control message transmission. 1064 Consider two peers, A and B. Suppose A specifies a Receive Window 1065 Size AVP with a value of N in the SCCRQ or SCCRP message. B is now 1066 allowed to have up to N outstanding control messages. Once N 1067 messages have been sent, B must wait for an acknowledgment from A 1068 that advances the window before sending new control messages. An 1069 implementation may support a receive window of only 1 (e.g. by 1070 sending out a Receive Window Size AVP with a value of 1), but MUST 1071 accept a window of up to 4 from its peer (i.e. have the ability to 1072 send 4 messages before backing off). A value of 0 for the Receive 1073 Window Size AVP is invalid. 1075 When retransmitting control messages, a slow start and congestion 1076 avoidance window adjustment procedure SHOULD be utilized. A 1077 recommended procedure is described in Appendix A. 1079 A peer MUST NOT withhold acknowledgment of messages as a technique 1080 for flow control of control messages. An L2TP implementation is 1081 expected to be able to keep up with incoming control messages, 1082 possibly responding to some with errors reflecting an inability to 1083 honor the requested actions. 1085 In addition, a peer MUST NOT withhold acknowledgment of messages in 1086 order to maintain state in the L2TP state machine. Conversely, the 1087 L2TP state machine MUST be capable of maintaining state if a ZLB ACK 1088 is received in response to a control message. However, determining 1089 when a state should no longer be maintained (e.g. how long to wait in 1090 wait-reply state for an ICRP from the peer) before destroying a 1091 session or control connection is an issue that is left to each 1092 implementation. 1094 Appendix B contains examples of control message transmission, 1095 acknowledgment, and retransmission. 1097 4.3 Control Connection Authentication 1099 L2TP incorporates a simple, optional, CHAP-like [RFC1994] 1100 authentication system for each LCCE during control connection 1101 establishment. If an LAC or LNS wishes to authenticate the identity 1102 of its peer, a Challenge AVP is included in the SCCRQ or SCCRP 1103 message. If a Challenge AVP is received in an SCCRQ or SCCRP, a 1104 Challenge Response AVP MUST be sent in the following SCCRP or SCCCN, 1105 respectively. If the expected response received from a peer does not 1106 match, establishment of the control connection MUST be disallowed. 1108 To participate in LCCE authentication, a single shared secret MUST 1109 exist between the two LCCEs. This is the same shared secret used for 1110 AVP hiding (see Section 5.3). See Section 5.4.3 for details on 1111 construction of the Challenge and Response AVPs. 1113 4.4 Keepalive (Hello) 1115 A keepalive mechanism is employed by L2TP to detect loss of 1116 connectivity between a pair of LCCEs. This detection is accomplished 1117 by injecting Hello control messages (see Section 6.5) after a 1118 specified period of time has elapsed since the last data message or 1119 control message was received on an L2TP session or control 1120 connection, respectively. As with any other control message, if the 1121 Hello message is not reliably delivered, the sending LCCE declares 1122 that the control connection is down and resets its state for the 1123 control connection. This behavior ensures that a connectivity 1124 failure between the LCCEs is detected independently by each end of a 1125 control connection. 1127 The sending of Hello messages and the policy for sending them are 1128 left up to the implementation. A peer MUST NOT expect Hello messages 1129 at any time or interval. As with all messages sent on the control 1130 connection, the receiver will return either a ZLB ACK or an 1131 (unrelated) message piggybacking the necessary acknowledgment 1132 information. 1134 If the control channel is operated in-band with data traffic over the 1135 PSN, this single mechanism can be used to infer basic data 1136 connectivity between a pair of LCCEs for all sessions associated with 1137 the control connection. 1139 Keepalives for the control connection MAY be implemented by sending a 1140 Hello if a period of time (a recommended default is 60 seconds, but 1141 SHOULD be configurable) has passed without receiving any message 1142 (data or control) from the peer. An LCCE sending Hello messages 1143 across multiple control connections between the same LCCE endpoints 1144 SHOULD employ a jittered timer mechanism. 1146 4.5 Forwarding Session Data Frames 1148 Once session establishment is complete, circuit frames are received 1149 at an LCCE, encapsulated in L2TP (with appropriate attention to 1150 framing as described in documents for the particular pseudowire 1151 type), and forwarded over the appropriate session. For every 1152 outgoing data message, the sender places the identifier specified in 1153 the Local Session ID AVP (received from peer during session 1154 establishment) in the Session ID field of the L2TP data header. In 1155 this manner, session frames are multiplexed and demultiplexed between 1156 a given pair of LCCEs. Multiple control connections may exist 1157 between a given pair of LCCEs, and multiple sessions may be 1158 associated with a given control connection. 1160 The peer LCCE receiving the L2TP data packet identifies the session 1161 with which the packet is associated by the Session ID in the data 1162 packet's header. The LCCE then checks the Cookie field in the data 1163 packet against the Cookie value received in the Assigned Cookie AVP 1164 during session establishment. Any received data packets that contain 1165 invalid Session IDs or associated Cookie values MUST be dropped. 1166 Finally, the LCCE either processes the encapsulated session frame 1167 locally (i.e. as an LNS) or forwards the frame to a circuit (i.e. as 1168 an LAC). 1170 4.6 Default PW Control Encapsulation 1172 This document defines a default PW control encapsulation (see Section 1173 3.2.2) format that a pseudowire may use for features such as basic 1174 sequencing support, marking of packets with a single high-priority 1175 bit, or other general PW-specific per-packet control operations. The 1176 default control encapsulation SHOULD be used by a given PW type to 1177 support these features if it is adequate, and its presence is 1178 requested by a peer during session negotiation. Alternative PW 1179 control encapsulations MAY be defined (e.g. an encapsulation with a 1180 larger Sequence Number field) and identified for use via the PW 1181 Control Encapsulation Type AVP. 1183 Figure 4.6: Default PW Control Encapsulation Format 1185 0 1 2 3 1186 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 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 |P|S|x|x|x|x|x|x| Sequence Number | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 The P (Priority) bit is used to identify a data packet that should be 1192 dropped only as a last resort after being received by an L2TP peer. 1193 This bit should be set to 1 for any traffic that should be given 1194 higher priority than other data traffic in a congested environment. 1195 For example, end-to-end L2 keepalive packets (e.g. LCP keepalives) or 1196 other control packets vital to the life of the circuit may need 1197 special handling by an LCCE upon receipt. This is not a replacement 1198 for, or to be used as, a per-hop QoS method of any sort. It is only 1199 to be used by the L2TP receiving node to prioritize incoming traffic. 1201 The S (Sequence) bit is set to 1 when the Sequence Number contains a 1202 valid number for this sequenced frame. If the S bit is set to zero, 1203 the Sequence Number contents are undefined and MUST be ignored by the 1204 receiver. 1206 The Sequence Number field contains a free-running counter of 2^24 1207 sequence numbers. If the number in this field is valid, the S bit 1208 MUST be set to 1. The Sequence Number begins at zero, which is a 1209 valid sequence number. (In this way, implementations inserting 1210 sequence numbers do not have to "skip" zero when incrementing.) The 1211 sequence number in the header of a received message is considered 1212 less than or equal to the last received number if its value lies in 1213 the range of the last received number and the preceding (2^23-1) 1214 values, inclusive. 1216 4.6.1 Sequencing Data Packets 1218 The Sequence Number field may be used to detect lost packets and/or 1219 restore the original sequence of packets that may have been reordered 1220 during traversal of the packet network. 1222 When L2 frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP 1223 data channel, this part of the link has the characteristic of being 1224 able to reorder or silently drop packets. Reordering may break some 1225 non-IP protocols or L2 control traffic being carried by the link. 1226 Silent dropping of packets may break protocols that assume per-packet 1227 indication of error, such as TCP header compression. The sequence 1228 dependency characteristics of individual protocols are outside the 1229 scope of this document. 1231 If any protocol being transported by over L2TP data channels cannot 1232 tolerate misordering, sequencing may be enabled on some or all 1233 packets by using the S bit and Sequence Number field defined in the 1234 default PW control encapsulation (see Section 4.6). For a given L2TP 1235 session, each LCCE is responsible for communicating to its peer the 1236 level of sequencing support that it requires of data packets that it 1237 receives. Mechanisms to advertise this information during session 1238 negotiation are provided (see, in particular, the Data Sequencing AVP 1239 in Section 5.4.4). PW-specific documents MAY place greater 1240 constraints on sequence number enforcement than those defined here. 1242 4.7 L2TPv2/v3 Interoperability and Migration 1244 L2TPv2 and L2TPv3 environments should be able to coexist while a 1245 migration to L2TPv3 is made. Migration issues are discussed for each 1246 media type in this section. Most issues apply only to 1247 implementations that require both L2TPv2 and L2TPv3 operation. 1248 However, even L2TPv3-only implementations must be mindful of these 1249 issues in order to interoperate with implementations that support 1250 both versions. 1252 4.7.1 L2TPv3 over IP 1254 L2TPv3 implementations running strictly over IP with no desire to 1255 interoperate with L2TPv2 implementations may safely disregard most 1256 migration issues from L2TPv2. All control messages and data messages 1257 are sent as described in this document. 1259 An L2TP implementation may first attempt to operate in L2TPv3 over IP 1260 mode, then fall back to L2TPv2 (over UDP) if L2TPv3 over IP is 1261 unavailable. It does so by first sending an L2TPv3-formatted SCCRQ 1262 over IP to try to initiate an L2TPv3 control connection. If the 1263 SCCRQ elicits no response, the implementation may fall back to L2TPv2 1264 operation, as defined in [RFC2661]. Fallback to L2TPv2 should be 1265 seamless and occur automatically. (See Section 4.7.3 for further 1266 details.) 1268 4.7.2 L2TPv3 over UDP 1270 In order to allow simultaneous operation with L2TPv2, L2TPv3 uses the 1271 same UDP port (port 1701) as L2TPv2 and shares the first two octets 1272 of header format (via the session header) with L2TPv2. Furthermore, 1273 though the control message and data message headers have changed, an 1274 LCCE sends an SCCRQ that looks enough like an L2TPv2 SCCRQ to be 1275 accepted by both L2TPv2 and L2TPv3 implementations. If the response 1276 to the SCCRQ is a properly formatted L2TPv3 message, then operation 1277 can continue as described in this document for an L2TPv3 1278 implementation. If the response is a properly formatted L2TPv2 1279 message, then an L2TPv2 mode of operation must be adopted. 1281 4.7.3 Automatic L2TPv2 Fallback 1283 When running over UDP, an implementation may detect whether a peer is 1284 L2TPv3-capable by sending an L2TPv3-formatted SCCRQ. The SCCRQ is 1285 sent with the Ver field set to 2, and any L2TPv3-specific AVPs within 1286 the message are sent without setting the M bit on each AVP (so that 1287 they may be ignored by an L2TPv2 implementation). Note that, in both 1288 L2TPv2 and L2TPv3, the value contained in the space of the control 1289 message header utilized by the 32-bit Control Connection ID (16-bit 1290 Tunnel ID and 16-bit Session ID in L2TPv2) is always 0 for an SCCRQ, 1291 a key feature for this capability. 1293 If the peer implementation is an L2TPv3-capable implementation, a 1294 control message with Ver set to 3 and corresponding header and 1295 message format will be sent in response to the SCCRQ. Operation may 1296 then continue as L2TPv3. If a message is received with Ver set to 2, 1297 one may assume that the peer implementation is L2TPv2-only and fall 1298 back to L2TPv2 mode if local policy and capability permits. 1300 The auto-detection mode requires that an L2TPv3-only implementation 1301 be liberal in its acceptance of SCCRQ control messages with the Ver 1302 field set to 2. Thus, an L2TPv3 over UDP implementation MUST allow 1303 receipt of an SCCRQ with Ver field of 2 or Ver field of 3. 1305 5. Control Message Attribute Value Pairs 1307 To maximize extensibility while still permitting interoperability, a 1308 uniform method for encoding message types and bodies is used 1309 throughout L2TP. This encoding will be termed AVP (Attribute Value 1310 Pair) for the remainder of this document. 1312 5.1 AVP Format 1314 Each AVP is encoded as follows: 1316 Figure 5.1: AVP Format 1318 0 1 2 3 1319 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 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 |M|H| rsvd | Length | Vendor ID | 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 | Attribute Type | Attribute Value... 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 (until Length is reached)... | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 The first six bits comprise a bit mask that describes the general 1329 attributes of the AVP. Two bits are defined in this document; the 1330 remaining bits are reserved for future extensions. Reserved bits 1331 MUST be set to 0. An AVP received with a reserved bit set to 1 MUST 1332 be treated as an unrecognized AVP. 1334 Mandatory (M) bit: Controls the behavior required of an 1335 implementation that receives an unrecognized or malformed AVP. The M 1336 bit of a given AVP should only be checked if the AVP is unrecognized 1337 or malformed. If the M bit is set on an unrecognized or malformed 1338 AVP in a control message associated with a particular session, the 1339 session MUST be terminated. If the M bit is set on an unrecognized 1340 or malformed AVP within a control message associated with a control 1341 connection, the control connection (and all sessions bound to the 1342 control connection) MUST be terminated. If the M bit is not set, an 1343 unrecognized AVP MUST be ignored. The control message must then 1344 continue to be processed as if the AVP had not been present. 1346 Hidden (H) bit: Identifies the hiding of data in the Attribute Value 1347 field of an AVP. This capability can be used to avoid the passing of 1348 sensitive data, such as user passwords, as cleartext in an AVP. 1349 Section 5.3 describes the procedure for performing AVP hiding. 1351 Length: Encodes the number of octets (including the Overall Length 1352 and bit mask fields) contained in this AVP. The Length may be 1353 calculated as 6 + the length of the Attribute Value field in octets. 1354 The field itself is 10 bits, permitting a maximum of 1023 octets of 1355 data in a single AVP. The minimum Length of an AVP is 6. If the 1356 Length is 6, then the Attribute Value field is absent. 1358 Vendor ID: The IANA assigned "SMI Network Management Private 1359 Enterprise Codes" [RFC1700] value. The value 0, corresponding to 1360 IETF adopted attribute values, is used for all AVPs defined within 1361 this document. Any vendor wishing to implement its own L2TP 1362 extensions can use its own Vendor ID along with private Attribute 1363 values, guaranteeing that they will not collide with any other 1364 vendor's extensions or future IETF extensions. Note that there are 1365 16 bits allocated for the Vendor ID, thus limiting this feature to 1366 the first 65,535 enterprises. 1368 Attribute Type: A 2-octet value with a unique interpretation across 1369 all AVPs defined under a given Vendor ID. 1371 Attribute Value: This is the actual value as indicated by the Vendor 1372 ID and Attribute Type. It follows immediately after the Attribute 1373 Type field and runs for the remaining octets indicated in the Length 1374 (i.e., Length minus 6 octets of header). This field is absent if the 1375 Length is 6. 1377 5.2 Mandatory AVPs 1379 Receipt of an unrecognized or malformed AVP that has the M bit set is 1380 catastrophic to the session or control connection with which it is 1381 associated. Thus, the M bit should only be defined for AVPs that are 1382 absolutely crucial to proper operation of the session or control 1383 connection. Furthermore, in the case in which the LAC or LNS 1384 receives an unknown AVP with the M bit set and shuts down the session 1385 or control connection accordingly, it is the full responsibility of 1386 the peer sending the Mandatory AVP to accept fault for causing a non- 1387 interoperable situation. Before defining an AVP with the M bit set, 1388 particularly a vendor-specific AVP, be sure that this consequence is 1389 intended. 1391 When an adequate alternative exists to use of the M bit, it should be 1392 utilized. For example, rather than simply sending an AVP with the M 1393 bit set to determine if a specific extension exists, availability may 1394 be identified by sending an AVP in a request message and expecting a 1395 corresponding AVP in a reply message. 1397 Use of the M bit with new AVPs (i.e. those not defined in this 1398 document) MUST provide the ability to configure the associated 1399 feature off, such that the AVP either is not sent or is sent with the 1400 M bit not set. 1402 On the receiving side, the recipient of a control message should only 1403 check the M bit of an AVP when the AVP is determined to be 1404 unrecognized or malformed. The M bit should not be checked for a 1405 recognized and well-formatted AVP. This rule prevents the 1406 possibility of a valid AVP resulting in a session or control 1407 connection teardown simply because its M bit was set to a value that 1408 was unexpected by the receiving LCCE. 1410 5.3 Hiding of AVP Attribute Values 1412 The H bit in the header of each AVP provides a mechanism to indicate 1413 to the receiving peer whether the contents of the AVP are hidden or 1414 present in cleartext. This feature can be used to hide sensitive 1415 control message data such as user passwords or user IDs. 1417 The H bit MUST only be set if (1) a shared secret exists between the 1418 LCCEs and (2) LCCE authentication has completed. The shared secret 1419 is the same secret that is used for LCCE authentication (see Section 1420 4.3). Hidden values MUST NOT be unhidden until after LCCE 1421 authentication has completed successfully (perhaps requiring the 1422 hidden value to be stored until after receipt of additional setup 1423 messages). To do otherwise runs the risk of AVP data being utilized 1424 without verifying the integrity of the shared secret. If the H bit 1425 is set in any AVP(s) in a given control message, a Random Vector AVP 1426 must also be present in the message and MUST precede the first AVP 1427 having an H bit of 1. 1429 Hiding an AVP value is done in several steps. The first step is to 1430 take the length and value fields of the original (cleartext) AVP and 1431 encode them into a Hidden AVP Subformat as follows: 1433 Figure 5.3: Hidden AVP Subformat 1435 0 1 2 3 1436 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 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | Length of Original Value | Original Attribute Value... 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 ... | Padding... 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 Length of Original Attribute Value: This is length of the Original 1444 Attribute Value to be obscured in octets. This is necessary to 1445 determine the original length of the Attribute Value that is lost 1446 when the additional Padding is added. 1448 Original Attribute Value: Attribute Value that is to be obscured. 1450 Padding: Random additional octets used to obscure length of the 1451 Attribute Value that is being hidden. 1453 To mask the size of the data being hidden, the resulting subformat 1454 MAY be padded as shown above. Padding does NOT alter the value 1455 placed in the Length of Original Attribute Value field, but does 1456 alter the length of the resultant AVP that is being created. For 1457 example, if an Attribute Value to be hidden is 4 octets in length, 1458 the unhidden AVP length would be 10 octets (6 + Attribute Value 1459 length). After hiding, the length of the AVP will become 6 + 1460 Attribute Value length + size of the Length of Original Attribute 1461 Value field + Padding. Thus, if Padding is 12 octets, the AVP length 1462 will be 6 + 4 + 2 + 12 = 24 octets. 1464 Next, an MD5 hash is performed (in network byte order) on the 1465 concatenation of the following: 1467 + the 2-octet Attribute number of the AVP 1468 + the shared secret 1469 + an arbitrary length random vector 1471 The value of the random vector used in this hash is passed in the 1472 value field of a Random Vector AVP. This Random Vector AVP must be 1473 placed in the message by the sender before any hidden AVPs. The same 1474 random vector may be used for more than one hidden AVP in the same 1475 message. If a different random vector is used for the hiding of 1476 subsequent AVPs, then a new Random Vector AVP must be placed in the 1477 command message before the first AVP to which it applies. 1479 The MD5 hash value is then XORed with the first 16-octet (or less) 1480 segment of the Hidden AVP Subformat and placed in the Attribute Value 1481 field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 1482 octets, the Subformat is transformed as if the Attribute Value field 1483 had been padded to 16 octets before the XOR. Only the actual octets 1484 present in the Subformat are modified, and the length of the AVP is 1485 not altered. 1487 If the Subformat is longer than 16 octets, a second one-way MD5 hash 1488 is calculated over a stream of octets consisting of the shared secret 1489 followed by the result of the first XOR. That hash is XORed with the 1490 second 16-octet (or less) segment of the Subformat and placed in the 1491 corresponding octets of the Value field of the Hidden AVP. 1493 If necessary, this operation is repeated, with the shared secret used 1494 along with each XOR result to generate the next hash to XOR the next 1495 segment of the value with. 1497 The hiding method was adapted from [RFC2138], which was taken from 1498 the "Mixing in the Plaintext" section in the book "Network Security" 1499 by Kaufman, Perlman and Speciner [KPS]. A detailed explanation of 1500 the method follows: 1502 Call the shared secret S, the Random Vector RV, and the Attribute 1503 Value AV. Break the value field into 16-octet chunks p1, p2, etc., 1504 with the last one padded at the end with random data to a 16-octet 1505 boundary. Call the ciphertext blocks c(1), c(2), etc. We will also 1506 define intermediate values b1, b2, etc. 1508 b1 = MD5(AV + S + RV) c(1) = p1 xor b1 1509 b2 = MD5(S + c(1)) c(2) = p2 xor b2 1510 . . 1511 . . 1512 . . 1513 bi = MD5(S + c(i-1)) c(i) = pi xor bi 1515 The String will contain c(1)+c(2)+...+c(i), where + denotes 1516 concatenation. 1518 On receipt, the random vector is taken from the last Random Vector 1519 AVP encountered in the message prior to the AVP to be unhidden. The 1520 above process is then reversed to yield the original value. 1522 5.4 AVP Summary 1524 The following sections contain a list of all L2TP AVPs defined in 1525 this document. 1527 Following the name of the AVP is a list indicating the message types 1528 that utilize each AVP. After each AVP title follows a short 1529 description of the purpose of the AVP, a detail (including a graphic) 1530 of the format for the Attribute Value, and any additional information 1531 needed for proper use of the AVP. 1533 5.4.1 AVPs Applicable to All Control Messages 1535 Message Type (All Messages) 1537 The Message Type AVP, Attribute Type 0, identifies the control 1538 message herein and defines the context in which the exact meaning of 1539 the following AVPs will be determined. 1541 The Attribute Value field for this AVP has the following format: 1543 0 1 1544 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | Message Type | 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 The Message Type is a 2-octet unsigned integer. 1551 The Message Type AVP MUST be the first AVP in a message, immediately 1552 following the control message header (defined in Section 3.2.1). See 1553 Section 3.1 for the list of defined control message types and their 1554 identifiers. 1556 The Mandatory (M) bit within the Message Type AVP has special 1557 meaning. Rather than an indication as to whether the AVP itself 1558 should be ignored if not recognized or malformed, it is an indication 1559 as to whether the control message itself should be ignored. If the M 1560 bit is set within the Message Type AVP and the Message Type is 1561 unknown to the implementation, the control connection MUST be 1562 cleared. If the M bit is not set, then the implementation may ignore 1563 an unknown message type. The M bit MUST be set to 1 for all message 1564 types defined in this document. This AVP MAY NOT be hidden (the H 1565 bit MUST be 0). The Length of this AVP is 8. 1567 A vendor-specific control message may be defined by setting the 1568 Vendor ID of the Message Type AVP to a value other than the IETF 1569 Vendor ID of 0 (see Section 5.1). The Message Type AVP MUST still be 1570 the first AVP in the control message. 1572 Random Vector (All Messages) 1574 The Random Vector AVP, Attribute Type 36, is used to enable the 1575 hiding of the Attribute Value of arbitrary AVPs. 1577 The Attribute Value field for this AVP has the following format: 1579 0 1 2 3 1580 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 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | Random Octet String... 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 The Random Octet String may be of arbitrary length, although a random 1586 vector of at least 16 octets is recommended. The string contains the 1587 random vector for use in computing the MD5 hash to retrieve or hide 1588 the Attribute Value of a hidden AVP (see Section 5.3). 1590 More than one Random Vector AVP may appear in a message, in which 1591 case a hidden AVP uses the Random Vector AVP most closely preceding 1592 it. This AVP MUST precede the first AVP with the H bit set. 1594 The M bit for this AVP SHOULD be set to 1. This AVP MUST NOT be 1595 hidden (the H bit MUST be 0). The Length of this AVP is 6 plus the 1596 length of the Random Octet String. 1598 5.4.2 Result and Error Codes 1600 Result Code (StopCCN, CDN) 1602 The Result Code AVP, Attribute Type 1, indicates the reason for 1603 terminating the control channel or session. 1605 The Attribute Value field for this AVP has the following format: 1607 0 1 2 3 1608 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 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 | Result Code | Error Code (optional) | 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 | Error Message (optional)... 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 The Result Code is a 2-octet unsigned integer. The optional Error 1616 Code is a 2-octet unsigned integer. An optional Error Message can 1617 follow the Error Code field. Presence of the Error Code and Message 1618 is indicated by the AVP Length field. The Error Message contains an 1619 arbitrary string providing further (human-readable) text associated 1620 with the condition. Human-readable text in all error messages MUST 1621 be provided in the UTF-8 charset using the Default Language 1622 [RFC2277]. 1624 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1625 this AVP SHOULD be set to 1. The Length is 8 if there is no Error 1626 Code or Message, 10 if there is an Error Code and no Error Message, 1627 or 10 + the length of the Error Message if there is an Error Code and 1628 Message. 1630 Defined Result Code values for the StopCCN message are as follows: 1632 0 - Reserved. 1633 1 - General request to clear control connection. 1634 2 - General error, Error Code indicates the problem. 1635 3 - Control channel already exists. 1636 4 - Requester is not authorized to establish a control channel. 1637 5 - The protocol version of the requester is not supported, 1638 Error Code indicates highest version supported. 1639 6 - Requester is being shut down. 1640 7 - Finite State Machine error. 1642 General Result Code values for the CDN message are as follows: 1644 0 - Reserved. 1645 1 - Session disconnected due to loss of carrier or circuit disconnect. 1646 2 - Session disconnected for the reason indicated in Error Code. 1647 3 - Session disconnected for administrative reasons. 1648 4 - Session establishment failed due to lack of appropriate 1649 facilities being available (temporary condition). 1650 5 - Session establishment failed due to lack of appropriate 1651 facilities being available (permanent condition). 1652 6 - 11 Reserved (PPP-specific codes defined outside this document). 1653 RC-TBA1 - Session not established due to losing tie-breaker. 1654 RC-TBA2 - Session not established due to unsupported PW type. 1655 RC-TBA3 - Session not established, sequencing required without valid 1656 PW control encapsulation. 1658 Additional service-specific Result Codes are defined outside this 1659 document. 1661 The Error Codes defined below pertain to types of errors that are not 1662 specific to any particular L2TP request, but rather to protocol or 1663 message format errors. If an L2TP reply indicates in its Result Code 1664 that a general error occurred, the General Error value should be 1665 examined to determine what the error was. The currently defined 1666 General Error codes and their meanings are as follows: 1668 0 - No general error. 1669 1 - No control connection exists yet for this pair of LCCEs. 1670 2 - Length is wrong. 1671 3 - One of the field values was out of range. 1672 4 - Insufficient resources to handle this operation now. 1673 5 - Invalid Session ID. 1674 6 - A generic vendor-specific error occurred. 1675 7 - Try another. If initiator is aware of other possible responder 1676 destinations, it should try one of them. This can be 1677 used to guide an LAC or LNS based on policy. 1678 8 - The session or control connection was shut down due to receipt of 1679 an unknown AVP with the M bit set (see Section 5.2). The Error 1680 Message SHOULD contain the attribute of the offending AVP in 1681 (human-readable) text form. 1682 9 - Try another directed. If an LAC or LNS is aware of other possible 1683 destinations, it should inform the initiator of the control 1684 connection or session. The Error Message MUST contain a 1685 comma-separated list of addresses from which the initiator may 1686 choose. If the L2TP data channel runs over IPv4, then this would 1687 be a comma-separated list of IP addresses in the canonical 1688 dotted-decimal format (e.g. "10.0.0.1, 10.0.0.2, 10.0.0.3") in the 1689 UTF-8 charset using the Default Language [RFC2277]. If there are 1690 no servers for the LAC or LNS to suggest, then Error Code 7 should 1691 be used. The delimiter between addresses MUST be precisely a 1692 single comma and a single space. 1694 When a General Error Code of 6 is used, additional information about 1695 the error SHOULD be included in the Error Message field. 1696 Furthermore, a vendor-specific AVP MAY be sent to indicate the 1697 problem more precisely. 1699 5.4.3 Control Connection Management AVPs 1701 Control Connection Tie-Breaker (SCCRQ) 1703 The Control Connection Tie-Breaker AVP, Attribute Type 5, indicates 1704 that the sender desires a single control connection to exist between 1705 a given pair of LCCEs. 1707 The Attribute Value field for this AVP has the following format: 1709 0 1 2 3 1710 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 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | Control Connection Tie-Breaker Value... 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 ...(64 bits) | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 The Control Connection Tie-Breaker Value is an 8-octet random value 1718 that is used to choose a single control connection when two LCCEs 1719 request a control connection concurrently. The recipient of a SCCRQ 1720 must check to see if a SCCRQ has been sent to the peer, and if so, 1721 must compare its Control Connection Tie-Breaker value with the 1722 received one. The lower value "wins", and the "loser" MUST discard 1723 its control connection, sending a StopCCN if the SCCRQ that it had 1724 sent was acknowledged by the receiving peer. In the case in which a 1725 tie-breaker is present on both sides and the value is equal, both 1726 sides MUST discard their control connections and restart control 1727 connection negotiation with a new, random tie-breaker value. 1729 If a tie-breaker is received and an outstanding SCCRQ has no tie- 1730 breaker value, the initiator that included the Control Connection 1731 Tie-Breaker AVP "wins". If neither side issues a tie-breaker, then 1732 two separate control connections are opened. 1734 Tie-breaker values MUST be random values. 1736 Note that in RFC 2661, this value was referred to as the Tie-Breaker 1737 AVP. Here, the AVP serves the same purpose and has the same 1738 attribute value and composition. 1740 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1741 this AVP SHOULD be set to 0. The Length of this AVP is 14. 1743 Host Name (SCCRQ, SCCRP) 1745 The Host Name AVP, Attribute Type 7, indicates the name of the 1746 issuing LAC or LNS. 1748 The Attribute Value field for this AVP has the following format: 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 | Host Name... 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 The Host Name is of arbitrary length, but MUST be at least 1 octet. 1758 This name should be as broadly unique as possible; for hosts 1759 participating in DNS [RFC1034], a hostname with fully qualified 1760 domain would be appropriate. The Host Name MAY be used to identify 1761 LCCE configuration, including the shared secret for LCCE 1762 authentication (if enabled) and any other options defined for the 1763 control connection. 1765 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1766 this AVP SHOULD be set to 1. The Length of this AVP is 6 plus the 1767 length of the Host Name. 1769 Vendor Name (SCCRQ, SCCRP) 1771 The Vendor Name AVP, Attribute Type 8, contains a vendor-specific 1772 (possibly human-readable) string describing the type of LAC or LNS 1773 being used. 1775 The Attribute Value field for this AVP has the following format: 1777 0 1 2 3 1778 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 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 | Vendor Name... 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 The Vendor Name is the indicated number of octets representing the 1783 vendor string. Human-readable text for this AVP MUST be provided in 1784 the UTF-8 charset using the Default Language [RFC2277]. 1786 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 1787 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6 1788 plus the length of the Vendor Name. 1790 Assigned Control Connection ID (SCCRQ, SCCRP, StopCCN) 1792 The Assigned Control Connection ID AVP, Attribute Type TBA, encodes 1793 the ID being assigned to this control connection by the sender. 1795 The Attribute Value field for this AVP has the following format: 1797 0 1 2 3 1798 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 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | Assigned Control Connection ID | 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 The Assigned Control Connection ID is a 4-octet non-zero unsigned 1804 integer. 1806 The Assigned Control Connection ID AVP establishes the identifier 1807 used to multiplex and demultiplex multiple control connections 1808 between a pair of LCCEs. Once the Assigned Control Connection ID AVP 1809 has been received by an LCCE, the Control Connection ID specified in 1810 the AVP MUST be included in the Control Connection ID field of all 1811 control packets sent to the peer for the lifetime of the control 1812 connection. Before the Assigned Control Connection ID AVP is 1813 received from a peer, all control messages MUST be sent to that peer 1814 with a Control Connection ID value of 0 in the header. Because a 1815 Control Connection ID value of 0 is used in this special manner, the 1816 zero value MUST NOT be sent as an Assigned Control Connection ID 1817 value. 1819 Under certain circumstances, an LCCE may need to send a StopCCN to a 1820 peer without having yet received an Assigned Control Connection ID 1821 AVP from the peer (i.e. SCCRQ sent, no SCCRP received yet). In this 1822 case, the Assigned Control Connection ID AVP that had been sent to 1823 the peer earlier (i.e. in the SCCRQ) MUST be sent as the Assigned 1824 Control Connection ID AVP in the StopCCN. This policy allows the 1825 peer to try to identify the appropriate control connection via a 1826 reverse lookup. 1828 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 1829 AVP SHOULD be set to 1 (see Section 4.7.3). The Length (before 1830 hiding) of this AVP is 10. 1832 Receive Window Size (SCCRQ, SCCRP) 1834 The Receive Window Size AVP, Attribute Type 10, specifies the receive 1835 window size being offered to the remote peer. 1837 The Attribute Value field for this AVP has the following format: 1839 0 1 1840 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 | Window Size | 1843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1845 The Window Size is a 2-octet unsigned integer. 1847 If absent, the peer must assume a Window Size of 4 for its transmit 1848 window. The remote peer may send the specified number of control 1849 messages before it must wait for an acknowledgment. See Section 4.2 1850 for more information on reliable control message delivery. 1852 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1853 this AVP SHOULD be set to 1. The Length of this AVP is 8. 1855 Challenge (SCCRQ, SCCRP) 1857 The Challenge AVP, Attribute Type 11, indicates that the issuing peer 1858 wishes to authenticate the LCCE using a CHAP-style authentication 1859 mechanism. 1861 The Attribute Value field for this AVP has the following format: 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 | Challenge... 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 The Challenge is one or more octets of random data. 1871 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 1872 AVP SHOULD be set to 1. The Length (before hiding) of this AVP is 6 1873 plus the length of the Challenge. 1875 Challenge Response (SCCRP, SCCCN) 1877 The Response AVP, Attribute Type 13, provides a response to a 1878 challenge received. 1880 The Attribute Value field for this AVP has the following format: 1882 0 1 2 3 1883 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 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 | Response... 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 ...(16 octets) | 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 The Response is a 16-octet value reflecting the CHAP-style [RFC1994] 1895 response to the challenge. 1897 This AVP MUST be present in an SCCRP or SCCCN if a challenge was 1898 received in the preceding SCCRQ or SCCRP, respectively. For purposes 1899 of the ID value in the CHAP response calculation, the value of the 1900 Message Type AVP for this message is used (e.g. 2 for an SCCRP, 3 for 1901 an SCCCN). 1903 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 1904 AVP SHOULD be set to 1. The Length (before hiding) of this AVP is 1905 22. 1907 Pseudowire Capabilities List (SCCRQ, SCCRP) 1909 The Pseudowire Capabilities List (PW Capabilities List) AVP, 1910 Attribute Type TBA, indicates the L2 payload types the sender can 1911 support. The specific payload type of a given session is identified 1912 by the Pseudowire Type AVP. 1914 The Attribute Value field for this AVP has the following format: 1916 0 1 2 3 1917 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 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 | PW Type 0 | ... | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 | ... | PW Type N | 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1924 Defined PW types that may appear in this list are outside the scope 1925 of this document and are managed by IANA. Values 0 to 32767 are 1926 assignable by IETF Consensus [RFC2434]. The remaining values may be 1927 assigned on a First Come First Served basis [RFC2434]. 1929 If a sender includes a given PW type in the PW Capabilities List AVP, 1930 the sender assumes full responsibility for supporting that particular 1931 payload, such as any payload-specific AVPs, PW control encapsulation, 1932 or control messages that may be defined in the appropriate companion 1933 document. 1935 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 1936 AVP SHOULD be set to 1 (see Section 4.7.3). The Length (before 1937 hiding) of this AVP is 8 octets with one PW type specified, plus 2 1938 octets for each additional PW type. 1940 5.4.4 Session Management AVPs 1942 Local Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI) 1944 The Local Session ID AVP (analogous to the Assigned Session ID in 1945 L2TPv2), Attribute Type TBA, encodes the identifier being assigned to 1946 this session by the sender. 1948 The Attribute Value field for this AVP has the following format: 1950 0 1 2 3 1951 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 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 | Local Session ID | 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 The Local Session ID is a 4-octet non-zero unsigned integer. 1958 The Local Session ID AVP establishes the identifier used to multiplex 1959 and demultiplex both data and control traffic for a given session 1960 between two LCCEs. The local LCCE chooses a free value that it sends 1961 to the remote LCCE using the Local Session ID AVP. The local LCCE 1962 then expects to see this value in the Session ID field of all 1963 received data messages for this session. Additionally, for all 1964 subsequent session-level control messages received, the local LCCE 1965 expects to see this session ID value echoed in the Remote Session ID 1966 AVP. On the other side, upon first receiving the Local Session ID 1967 AVP in a control message, the remote LCCE MUST use this value for all 1968 subsequent messages sent to the local LCCE for this session. The 1969 value must appear in the Session ID field in the header of all 1970 outgoing data messages for this session, and as the Remote Session ID 1971 AVP of all outgoing control messages for this session. 1973 See Section 4.1 for additional information about the Session ID. 1975 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 1976 AVP MUST be 1 for implementations that support only L2TPv3 (see 1977 Section 4.7 for L2TPv2 migration issues). The Length (before hiding) 1978 of this AVP is 10. 1980 Remote Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI) 1982 The Remote Session ID AVP, Attribute Type TBA, encodes the identifier 1983 that was assigned to this session by the peer. 1985 The Attribute Value field for this AVP has the following format: 1987 0 1 2 3 1988 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 1989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1990 | Remote Session ID | 1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 The Remote Session ID is a 4-octet non-zero unsigned integer. 1995 The Remote Session ID AVP MUST be present in all session-level 1996 control messages. The AVP's value echoes the session identifier 1997 advertised by the peer via the Local Session ID AVP. It is the same 1998 value that will be used in all transmitted data messages by this side 1999 of the session. In most cases, this identifier is sufficient for the 2000 peer to look up session-level context for this control message. 2002 When a session-level control message must be sent to the peer before 2003 the Local Session ID AVP has been received from the peer, the value 2004 of the Remote Sesson ID AVP MUST be set to zero. Additionally, the 2005 Local Session ID AVP (sent in a previous control message for this 2006 session) MUST be included in the control message. The peer must then 2007 use the Local Session ID AVP to perform a "reverse lookup" to find 2008 its session context. Session-level control messages defined in this 2009 document that might be subject to a reverse lookup by a receiving 2010 peer include the CDN, WEN, and SLI. 2012 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2013 AVP MUST be 1 for implementations that support only L2TPv3 (see 2014 Section 4.7 for L2TPv2 migration issues). The Length (before hiding) 2015 of this AVP is 10. 2017 Assigned Cookie (ICRQ, ICRP, OCRQ, OCRP) 2019 The Assigned Cookie AVP, Attribute Type TBA, encodes the Cookie value 2020 being assigned to this session by the sender. 2022 The Attribute Value field for this AVP has the following format: 2024 0 1 2 3 2025 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 2026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2027 | Assigned Cookie (32 or 64 bits)... 2028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 The Assigned Cookie is a 4-octet or 8-octet random value. 2032 The Assigned Cookie AVP contains the value used to check the 2033 association of a received data message with the session identified by 2034 the Session ID. All data messages sent to a peer MUST use the 2035 Assigned Cookie sent by the peer in this AVP. The value's length (0, 2036 32, or 64 bits) is obtained by the Length of the AVP. A cookie value 2037 of zero length serves as positive acknowledgment that the Cookie 2038 field should not be present in any data packets sent to this LCCE. 2039 The Assigned Cookie AVP MAY not be sent, which has the same effect as 2040 sending the AVP to designate a cookie value of zero length. 2042 See Section 4.1 for additional information about the Assigned Cookie. 2044 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2045 AVP MUST be 1 for implementations that support only L2TPv3 (see 2046 Section 4.7 for L2TPv2 migration issues). The Length (before hiding) 2047 of this AVP may be 6, 10, or 14 octets. 2049 Session Serial Number (ICRQ, OCRQ) 2051 The Session Serial Number AVP, Attribute Type 15, encodes an 2052 identifier assigned by the LAC or LNS to this session. 2054 The Attribute Value field for this AVP has the following format: 2056 0 1 2 3 2057 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 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 | Session Serial Number | 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 The Session Serial Number is a 32-bit value. 2064 The Session Serial Number is intended to be an easy reference for 2065 administrators on both ends of a control connection to use when 2066 investigating session failure problems. Session Serial Numbers 2067 should be set to progressively increasing values, which are likely to 2068 be unique for a significant period of time across all interconnected 2069 LNSs and LACs. 2071 Note that in RFC 2661, this value was referred to as the Call Serial 2072 Number AVP. It serves the same purpose and has the same attribute 2073 value and composition. 2075 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2076 AVP SHOULD be set to 1. The Length (before hiding) of this AVP is 2077 10. 2079 End Identifier (ICRQ, OCRQ) 2081 The End Identifier AVP, Attribute Type TBA, encodes an identifier 2082 used to associate an attachment circuit with a request for an L2TP 2083 session. This AVP allows an LCCE to determine when a session request 2084 "tie" has occurred. 2086 The Attribute Value field for this AVP has the following format: 2088 0 1 2 3 2089 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 2090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2091 | End Identifier ... (arbitrary number of octets) 2092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 Use of the End Identifier AVP implies that the session follows the 2095 "LAC-LAC" reference model. The End Identifier MUST contain 2096 interface, circuit, or remote system information, depending on the 2097 circuit that is being tunneled. For example, the field may be a 2098 simple 4-octet binary value, a VPN Identifier (as described in 2099 [RFC2764]), or an ASCII string. In the simplest case, this value is 2100 one that is locally configured, though a directory query MAY be made 2101 with this value to obtain additional information about this session 2102 request. 2104 A session-level tie is detected if an LCCE receives an ICRQ or OCRQ 2105 with an End Identifier AVP whose value and length matches the End 2106 Identifier AVP that was just sent in an outgoing ICRQ or OCRQ to the 2107 same peer. If the two values match, an LCCE recognizes that a tie 2108 exists (i.e. both LCCEs are attempting to establish sessions for the 2109 same circuit). The tie is broken by the dominant LCCE, as determined 2110 by the Session Tie-Breaker AVP. 2112 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2113 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6 2114 plus the length of the End Identifier value. 2116 Session Tie-Breaker (ICRQ, OCRQ) 2118 The Session Tie-Breaker AVP, Attribute Type TBD, is used to break 2119 ties when two peers concurrently attempt to establish a session for 2120 the same circuit. 2122 The Attribute Value field for this AVP has the following format: 2124 0 1 2 3 2125 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 2126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2127 | Session Tie-Breaker Value... 2128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2129 ...(64 bits) | 2130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 The Session Tie-Breaker Value is an 8-octet random value that is used 2133 to choose a session when two LCCEs concurrently request a session for 2134 the same circuit, as determined by the End Identifier AVP. The 2135 recipient of an ICRQ or OCRQ must check to see if an ICRQ or OCRQ, 2136 respectively, already has been sent to the peer for the same circuit, 2137 and if so, must compare its Session Tie-Breaker Value with the one 2138 received. The lower value "wins", and the "loser" MUST send a CDN 2139 with result code set to RC-TBA1 (as defined in Section 5.4.2) to tear 2140 down the session it instigated. In the case in which a tie-breaker 2141 is present on both sides and the value is equal, both sides MUST 2142 discard their sessions and restart session negotiation with new 2143 random Session Tie-Breaker Values. 2145 If a tie-breaker is received and an outstanding ICRQ/OCRQ has no tie 2146 breaker value, the initiator that included the Session Tie-Breaker 2147 AVP "wins". If neither side issues a tie breaker, then both sessions 2148 MUST be torn down. 2150 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 2151 this AVP SHOULD be set to 0. The Length of this AVP is 14. 2153 Pseudowire Type (ICRQ, OCRQ) 2155 The Pseudowire Type (PW Type) AVP, Attribute Type TBA, indicates the 2156 L2 payload type of the packets that will be tunneled using this L2TP 2157 session. 2159 The Attribute Value field for this AVP has the following format: 2161 0 1 2162 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 | PW Type | 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 A peer MUST NOT request an incoming or outgoing call with a PW Type 2168 AVP specifying a value not advertised in the PW Capabilities List AVP 2169 it received during control connection establishment. Attempts to do 2170 so MUST result in the call being rejected via a CDN with the Result 2171 Code set to RC-TBA2 (see Section 5.4.2). 2173 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2174 AVP MUST be 1 for implementations that support only L2TPv3 (see 2175 Section 4.7 for L2TPv2 migration issues). The Length (before hiding) 2176 of this AVP is 8. 2178 Pseudowire Control Encapsulation (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2180 The Pseudowire Control Encapsulation (PW Control Encapsulation) AVP, 2181 Attribute Type TBA, indicates the type of PW control encapsulation 2182 the sender of this AVP requires to be present on all incoming data 2183 packets for this L2TP session. 2185 0 1 2186 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2188 | PW Control Encapsulation | 2189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 The Control Encapsulation Type is a 2-octet unsigned integer with the 2192 following values defined in this document: 2194 0 - There is no control encapsulation present. 2195 1 - The default PW control encapsulation (defined in Section 4.6) 2196 is used. 2198 If this AVP is included in any of the above control messages and has 2199 a value other than zero, the receiving LCCE MUST include the 2200 identified control encapsulation in its outgoing data messages. 2202 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2203 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 8. 2205 Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2207 The Data Sequencing AVP, Attribute Type TBA, indicates that the 2208 sender requires some or all of the incoming data packets to be 2209 sequenced. 2211 The Attribute Value field for this AVP has the following format: 2213 0 1 2214 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 | Data Sequencing Level | 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2219 The Data Sequencing Level is a 2-octet unsigned integer indicating 2220 the degree of incoming data traffic that the sender of this AVP 2221 wishes to be marked with sequence numbers. 2223 The following values are valid data sequencing levels: 2225 0 - No incoming data require sequencing. 2226 1 - Only non-IP data require sequencing. 2227 2 - All incoming data require sequencing. 2229 If a data sequencing level of 0 is specified, there is no need to 2230 send packets with sequence numbers. If sequence numbers are sent, 2231 they will be ignored upon receipt. 2233 If a data sequencing level of 1 is specified, only non-IP traffic 2234 carried within the given PW-specific framing should have sequence 2235 numbers applied. All traffic that can be classified as IP SHOULD be 2236 sent with no sequencing. If a packet is unable to be classified at 2237 all or if an implementation is unable to perform such classification, 2238 all packets MUST be provided with sequence numbers (essentially, a 2239 data sequencing level of 2). 2241 If a data sequencing level of 2 is specified, all traffic MUST be 2242 sequenced. 2244 The method of sequencing is dependent upon the PW type and the PW 2245 control encapsulation. If the PW does not have any other data 2246 sequencing abilities above L2TP, a PW control encapsulation with 2247 sequence number support MUST be requested. Thus, in most cases, it 2248 is a protocol violation to send the Data Sequencing AVP without also 2249 specifying a PW control encapsulation that can be used to provide 2250 sequencing support. If such a violation occurs, the session SHOULD 2251 be disconnected with a Result Code of RC-TBA3. 2253 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2254 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6. 2256 Tx Connect Speed (ICRQ, ICRP, ICCN) 2258 The Tx Connect Speed BPS AVP, Attribute Type 24, encodes the speed of 2259 the facility chosen for the connection attempt. 2261 The Attribute Value field for this AVP has the following format: 2263 0 1 2 3 2264 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 2265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2266 | BPS (H) | BPS (L) | 2267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 The Tx Connect Speed BPS is a 4-octet value indicating the speed in 2270 bits per second. A value of zero indicates that the speed is 2271 indeterminable or that there is no physical point-to-point link. 2273 When the optional Rx Connect Speed AVP is present, the value in this 2274 AVP represents the transmit connect speed from the perspective of the 2275 LAC (e.g. data flowing from the LAC to the remote system). When the 2276 optional Rx Connect Speed AVP is NOT present, the connection speed 2277 between the remote system and LAC is assumed to be symmetric and is 2278 represented by the single value in this AVP. 2280 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2281 AVP SHOULD be set to 1. The Length (before hiding) of this AVP is 2282 10. 2284 Rx Connect Speed (ICRQ, ICRP, ICCN) 2286 The Rx Connect Speed AVP, Attribute Type 38, represents the speed of 2287 the connection from the perspective of the LAC (e.g. data flowing 2288 from the remote system to the LAC). 2290 The Attribute Value field for this AVP has the following format: 2292 0 1 2 3 2293 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 2294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2295 | BPS (H) | BPS (L) | 2296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2298 BPS is a 4-octet value indicating the speed in bits per second. A 2299 value of zero indicates that the speed is indeterminable or that 2300 there is no physical point-to-point link. 2302 Presence of this AVP implies that the connection speed may be 2303 asymmetric with respect to the transmit connect speed given in the Tx 2304 Connect Speed AVP. 2306 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2307 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 2308 10. 2310 Physical Channel ID (ICRQ, ICRP, OCRP) 2312 The Physical Channel ID AVP, Attribute Type 25, encodes the vendor- 2313 specific physical channel number used for a call. 2315 The Attribute Value field for this AVP has the following format: 2317 0 1 2 3 2318 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 2319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2320 | Physical Channel ID | 2321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2323 Physical Channel ID is a 4-octet value intended to be used for 2324 logging purposes only. 2326 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2327 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 2328 10. 2330 5.4.5 Circuit Status AVPs 2332 Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI) 2334 The Circuit Status AVP, Attribute Type TBA, indicates the initial 2335 status of or a status change in the circuit to which the session is 2336 bound. 2338 The Attribute Value field for this AVP has the following format: 2340 0 1 2341 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2343 | Reserved |N|A| 2344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 The A (Active) bit indicates whether the circuit is up/active/ready 2347 (1) or down/inactive/not-ready (0). 2349 The N (New) bit indicates whether the circuit status indication is 2350 for a new circuit (1) or an existing circuit (0). 2352 The remaining bits are reserved for future use. Reserved bits MUST 2353 be set to 0 when sending and ignored upon receipt. 2355 The Circuit Status AVP is used to advertise whether a circuit or 2356 interface bound to an L2TP session is up and ready to send and/or 2357 receive traffic. Various circuit types have different names for 2358 these status types. For instance, HDLC primary and secondary 2359 stations refer to a circuit as being "Receive Ready" or "Receive Not 2360 Ready", while Frame Relay refers to a circuit as "Active" or 2361 "Inactive". This AVP adopts the latter terminology, though the 2362 concept remains the same regardless of the PW type being tunneled. 2364 The Circuit Status MUST be advertised in this AVP when an L2TP 2365 session is initiated by an ICRQ or OCRQ. Often, the circuit type 2366 will be marked Active when initiated, but MAY be advertised as 2367 Inactive, indicating that an L2TP session is to be created but that 2368 the interface or circuit is still not ready to pass traffic. The 2369 ICCN, OCCN, and SLI control messages all MAY contain this AVP to 2370 update the status of the circuit after establishment of the L2TP 2371 session is requested. 2373 If additional circuit status information is needed for a given PW 2374 type, PW-specific AVPs MUST be defined in a separate document for 2375 that information. This AVP is only for general circuit status 2376 information applicable to all circuit/interface types. 2378 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2379 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 8. 2381 Circuit Errors (WEN) 2383 The Circuit Errors AVP, Attribute Type 34, conveys circuit error 2384 information to the peer. 2386 The Attribute Value field for this AVP has the following format: 2388 0 1 2 3 2389 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 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2391 | Reserved | 2392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2393 | Hardware Overruns | 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 | Buffer Overruns | 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 | Timeout Errors | 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 | Alignment Errors | 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2402 The following fields are defined: 2404 Reserved: 2 octets of Reserved data is present (providing longword 2405 alignment within the AVP of the following values). Reserved 2406 data MUST be zero on sending and ignored upon receipt. 2407 Hardware Overruns: Number of receive buffer overruns since call 2408 was established. 2409 Buffer Overruns: Number of buffer overruns detected since call was 2410 established. 2411 Timeout Errors: Number of timeouts since call was established. 2412 Alignment Errors: Number of alignment errors since call was 2413 established. 2415 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2416 AVP SHOULD be set to 1. The Length (before hiding) of this AVP is 2417 32. 2419 6. Control Connection Protocol Specification 2421 The following control messages are used to establish, maintain, and 2422 tear down L2TP control connections. All data are sent in network 2423 order (high-order octets first). Any "reserved" or "empty" fields 2424 MUST be sent as 0 values to allow for protocol extensibility. 2426 The exchanges in which these messages are involved are outlined in 2427 Section 3.3. 2429 6.1 Start-Control-Connection-Request (SCCRQ) 2431 Start-Control-Connection-Request (SCCRQ) is a control message used to 2432 initiate a control connection between two LCCEs. It is sent by 2433 either the LAC or the LNS to begin the control connection 2434 establishment process. 2436 The following AVPs MUST be present in the SCCRQ: 2438 Message Type AVP 2439 Host Name 2440 Assigned Control Connection ID 2441 Pseudowire Capabilities List 2443 The following AVPs MAY be present in the SCCRQ: 2445 Receive Window Size 2446 Challenge 2447 Control Connection Tie-Breaker 2448 Vendor Name 2450 6.2 Start-Control-Connection-Reply (SCCRP) 2452 Start-Control-Connection-Reply (SCCRP) is the control message sent in 2453 reply to a received SCCRQ message. The SCCRP is used to indicate 2454 that the SCCRQ was accepted and establishment of the control 2455 connection should continue. 2457 The following AVPs MUST be present in the SCCRP: 2459 Message Type 2460 Host Name 2461 Assigned Control Connection ID 2462 Pseudowire Capabilities List 2464 The following AVPs MAY be present in the SCCRP: 2466 Firmware Revision 2467 Vendor Name 2468 Receive Window Size 2469 Challenge 2470 Challenge Response 2472 6.3 Start-Control-Connection-Connected (SCCCN) 2474 Start-Control-Connection-Connected (SCCCN) is the control message 2475 sent in reply to an SCCRP. The SCCCN completes the control 2476 connection establishment process. 2478 The following AVP MUST be present in the SCCCN: 2480 Message Type 2482 The following AVP MAY be present in the SCCCN: 2484 Challenge Response 2486 6.4 Stop-Control-Connection-Notification (StopCCN) 2488 Stop-Control-Connection-Notification (StopCCN) is the control message 2489 sent by either LCCE to inform its peer that the control connection is 2490 being shut down and that the control connection should be closed. In 2491 addition, all active sessions are implicitly cleared (without sending 2492 any explicit session control messages). The reason for issuing this 2493 request is indicated in the Result Code AVP. There is no explicit 2494 reply to the message, only the implicit ACK that is received by the 2495 reliable control message delivery layer. 2497 The following AVPs MUST be present in the StopCCN: 2499 Message Type 2500 Result Code 2502 The following AVP MAY be present in the StopCCN: 2504 Assigned Control Connection ID 2506 Note that the Assigned Control Connection ID MUST be present if the 2507 StopCCN is sent after an SCCRQ or SCCRP message has been sent. 2509 6.5 Hello (HELLO) 2511 The Hello (HELLO) message is an L2TP control message sent by either 2512 peer of a control connection. This control message is used as a 2513 "keepalive" for the control connection. See Section 4.2 for a 2514 description of the keepalive mechanism. 2516 HELLO messages are global to the control connection. The Session ID 2517 in a HELLO message MUST be 0. 2519 The following AVP MUST be present in the HELLO: 2521 Message Type 2523 6.6 Incoming-Call-Request (ICRQ) 2525 Incoming-Call-Request (ICRQ) is the control message sent by an LCCE 2526 to a peer when an incoming call is detected (although the ICRQ may 2527 also be sent as a result of a local event). It is the first in a 2528 three-message exchange used for establishing a session via an L2TP 2529 control connection. 2531 The ICRQ is used to indicate that a session is to be established 2532 between an LCCE and a peer. The sender of an ICRQ provides the peer 2533 with parameter information for the session. However, the sender 2534 makes no demands about how the session is terminated at the peer 2535 (i.e. whether the L2 traffic is processed locally, forwarded, etc.). 2537 The following AVPs MUST be present in the ICRQ: 2539 Message Type 2540 Local Session ID 2541 Remote Session ID 2542 Call Serial Number 2543 Pseudowire Type 2544 Pseudowire Control Encapsulation 2545 Data Sequencing 2546 Circuit Status 2548 The following AVP MAY be present in the ICRQ: 2550 Assigned Cookie 2551 End Identifier 2552 Session Tie-Breaker 2553 Physical Channel ID 2554 Tx Connect Speed 2555 Rx Connect Speed 2557 6.7 Incoming-Call-Reply (ICRP) 2559 Incoming-Call-Reply (ICRP) is the control message sent by an LCCE in 2560 response to a received ICRQ. It is the second in the three-message 2561 exchange used for establishing sessions within an L2TP control 2562 connection. 2564 The ICRP is used to indicate that the ICRQ was successful and that 2565 the peer should establish (i.e. answer) the incoming call if it has 2566 not already done so. It also allows the sender to indicate specific 2567 parameters about the L2TP session. 2569 The following AVPs MUST be present in the ICRP: 2571 Message Type 2572 Local Session ID 2573 Remote Session ID 2574 Pseudowire Control Encapsulation 2575 Data Sequencing 2576 Circuit Status 2578 The following AVP MAY be present in the ICRP: 2580 Assigned Cookie 2581 Physical Channel ID 2582 Tx Connect Speed 2583 Rx Connect Speed 2585 6.8 Incoming-Call-Connected (ICCN) 2587 Incoming-Call-Connected (ICCN) is the control message sent by the 2588 LCCE that originally sent an ICRQ upon receiving an ICRP from its 2589 peer. It is the final message in the three-message exchange used for 2590 establishing L2TP sessions. 2592 The ICCN is used to indicate that the ICRP was accepted, that the 2593 call has been established, and that the L2TP session should move to 2594 the established state. It also allows the sender to indicate 2595 specific parameters about the established call (parameters that may 2596 not have been available at the time the ICRQ is issued). 2598 The following AVPs MUST be present in the ICCN: 2600 Message Type 2601 Local Session ID 2602 Remote Session ID 2604 The following AVPs MAY be present in the ICCN: 2606 Pseudowire Control Encapsulation 2607 Data Sequencing 2608 Circuit Status 2609 Tx Connect Speed 2610 Rx Connect Speed 2612 6.9 Outgoing-Call-Request (OCRQ) 2614 Outgoing-Call-Request (OCRQ) is the control message sent by an LCCE 2615 to an LAC to indicate that an outbound call at the LAC is to be 2616 established based on specific destination information sent in this 2617 message. It is the first in a three-message exchange used for 2618 establishing a session and placing a call on behalf of the initiating 2619 LCCE. 2621 Note that a call may be any L2 connection requiring well-known 2622 destination information to be sent from an LCCE to an LAC. This call 2623 could be a dialup connection to the PSTN, an SVC connection, the IP 2624 address of another LCCE, or any other destination dictated by the 2625 sender of this message. 2627 The following AVPs MUST be present in the OCRQ: 2629 Message Type 2630 Local Session ID 2631 Remote Session ID 2632 Call Serial Number 2633 Pseudowire Type 2634 Pseudowire Control Encapsulation 2635 Data Sequencing 2636 Circuit Status 2638 The following AVPs MAY be present in the OCRQ: 2640 Assigned Cookie 2641 End Identifier 2642 Session Tie-Breaker 2644 6.10 Outgoing-Call-Reply (OCRP) 2646 Outgoing-Call-Reply (OCRP) is the control message sent by an LAC to 2647 an LCCE in response to a received OCRQ. It is the second in a three- 2648 message exchange used for establishing a session within an L2TP 2649 control connection. 2651 OCRP is used to indicate that the LAC has been able to attempt the 2652 outbound call. The message returns any relevant parameters regarding 2653 the call attempt. Data MUST not be forwarded until the OCCN is 2654 received indicating that the call has been placed. 2656 The following AVPs MUST be present in the OCRP: 2658 Message Type 2659 Local Session ID 2660 Remote Session ID 2661 Pseudowire Control Encapsulation 2662 Data Sequencing 2663 Circuit Status 2665 The following AVPs MAY be present in the OCRP: 2667 Assigned Cookie 2668 Physical Channel ID 2670 6.11 Outgoing-Call-Connected (OCCN) 2672 Outgoing-Call-Connected (OCCN) is the control message sent by an LAC 2673 to another LCCE after the OCRP and after the outgoing call has been 2674 completed. It is the final message in a three-message exchange used 2675 for establishing a session. 2677 OCCN is used to indicate that the result of a requested outgoing call 2678 was successful. It also provides information to the LCCE who 2679 requested the call about the particular parameters obtained after the 2680 call was established. 2682 The following AVPs MUST be present in the OCCN: 2684 Message Type 2685 Local Session ID 2686 Remote Session ID 2688 The following AVPs MAY be present in the OCCN: 2690 Pseudowire Control Encapsulation 2691 Data Sequencing 2692 Circuit Status 2694 6.12 Call-Disconnect-Notify (CDN) 2696 The Call-Disconnect-Notify (CDN) is a control message sent by an LCCE 2697 to request disconnection of a specific session. Its purpose is to 2698 inform the peer of the disconnection and the reason for the 2699 disconnection. The peer MUST clean up any resources, and does not 2700 send back any indication of success or failure for such cleanup. 2702 The following AVPs MUST be present in the CDN: 2704 Message Type 2705 Local Session ID 2706 Remote Session ID 2707 Result Code 2709 6.13 WAN-Error-Notify (WEN) 2711 The WAN-Error-Notify (WEN) is a control message sent from an LAC to an 2712 LNS to indicate WAN error conditions. The counters in this message 2713 are cumulative. This message should only be sent when an error 2714 occurs, and not more than once every 60 seconds. The counters are 2715 reset when a new call is established. 2717 The following AVPs MUST be present in the WEN: 2719 Message Type 2720 Circuit Errors 2721 Local Session ID 2722 Remote Session ID 2724 6.14 Set-Link-Info (SLI) 2726 The Set-Link-Info control message is sent by an LCCE to convey link 2727 or circuit status change information regarding the circuit associated 2728 with this L2TP session. For example, if PPP renegotiates LCP or a 2729 Frame Relay VC transitions to Active or Inactive, an SLI message 2730 SHOULD be sent to indicate this event. Precise details of when the 2731 SLI is sent, what PW type-specific AVPs must be present, and how 2732 those AVPs should be interpreted by the receiving peer are outside 2733 the scope of this document. These details should be described in the 2734 associated payload-specific documents that require use of this 2735 message. 2737 The following AVPs MUST be present in the SLI: 2739 Message Type 2740 Local Session ID 2741 Remote Session ID 2743 The following AVPs MAY be present in the SLI: 2745 Circuit Status 2747 7. Control Connection State Machines 2749 The state tables defined in this section govern the exchange of 2750 control messages defined in Section 6. Tables are defined for 2751 incoming call placement and outgoing call placement, as well as for 2752 initiation of the control connection itself. The state tables do not 2753 encode timeout and retransmission behavior, as this is handled in the 2754 underlying reliable control message delivery mechanism (see Section 2755 4.2). 2757 7.1 Malformed Control Messages 2759 Receipt of an invalid or unrecoverable malformed control message 2760 SHOULD be logged appropriately and the control connection cleared to 2761 ensure recovery to a known state. The control connection may then be 2762 restarted by the initiator. 2764 An invalid control message is defined as (1) a message that contains 2765 a Message Type marked as mandatory (see Section 5.4.1) but that is 2766 unknown to the implementation, or (2) a control message that is 2767 received in the wrong state. 2769 Examples of malformed control messages include (1) a message that has 2770 an invalid value in its header, (2) a message that contains an AVP 2771 that is formatted incorrectly or whose value is out of range, and (3) 2772 a message that is missing a required AVP. A control message with a 2773 malformed header MUST be discarded. 2775 If a malformed AVP is received with the M bit set, the session or 2776 control connection MUST be terminated with a proper Result or Error 2777 Code sent. A malformed yet non-mandatory (M bit is not set) AVP 2778 within a control message should be handled like an unrecognized non- 2779 mandatory AVP. That is, the AVP MUST be ignored (with the exception 2780 of logging a local error message), and the message MUST be accepted. 2782 This policy MUST NOT be considered a license to send malformed AVPs, 2783 but rather, a guide towards how to handle an improperly formatted 2784 message if one is received. It is impossible to list all potential 2785 malformations of a given message and give advice for each. That 2786 said, one example of a recoverable, malformed AVP might be if the Rx 2787 Connect Speed AVP, attribute 38, is received with a length of 8 2788 rather than 10, and the BPS given in 2 octets rather than 4. Since 2789 the Rx Connect Speed is non-mandatory, this condition should not be 2790 considered catastrophic. As such, the control message should be 2791 accepted as if the AVP had not been received (with the exception of a 2792 local error message being logged). 2794 In several cases in the following tables, a protocol message is sent, 2795 and then a "clean up" occurs. Note that, regardless of the initiator 2796 of the control connection destruction, the reliable delivery 2797 mechanism must be allowed to run (see Section 4.2) before destroying 2798 the control connection. This permits the control connection 2799 management messages to be reliably delivered to the peer. 2801 Appendix B.1 contains an example of lock-step control connection 2802 establishment. 2804 7.2 Timing Considerations 2806 Due to the real-time nature of L2 circuit signaling, an LCCE should 2807 be implemented using a multi-threaded architecture such that messages 2808 related to multiple calls are not serialized and blocked. The call 2809 and connection state figures do not specify exceptions caused by 2810 timers. 2812 7.3 Control Connection States 2814 The L2TP control connection protocol is not distinguishable between 2815 the two LCCEs but is distinguishable between the originator and 2816 receiver. The originating peer is the one that first initiates 2817 establishment of the control connection. (In a tie-breaker 2818 situation, this is the winner of the tie.) Since either the LAC or 2819 the LNS can be the originator, a collision can occur. See the 2820 Control Connection Tie-Breaker AVP in Section 5.4.3 for a description 2821 of this and its resolution. 2823 State Event Action New State 2824 ----- ----- ------ --------- 2825 idle Local open Send SCCRQ wait-ctl-reply 2826 request 2828 idle Receive SCCRQ, Send SCCRP wait-ctl-conn 2829 acceptable 2831 idle Receive SCCRQ, Send StopCCN, idle 2832 not acceptable clean up 2834 idle Receive SCCRP Send StopCCN, idle 2835 clean up 2837 idle Receive SCCCN Clean up idle 2839 wait-ctl-reply Receive SCCRP, Send SCCCN, established 2840 acceptable send control-conn 2841 open event to 2842 waiting sessions 2844 wait-ctl-reply Receive SCCRP, Send StopCCN, idle 2845 not acceptable clean up 2847 wait-ctl-reply Receive SCCRQ, Clean up, idle 2848 lose tie-breaker re-queue SCCRQ 2849 for idle state 2851 wait-ctl-reply Receive SCCCN Send StopCCN, idle 2852 clean up 2854 wait-ctl-conn Receive SCCCN, Send control-conn established 2855 acceptable open event to 2856 waiting sessions 2858 wait-ctl-conn Receive SCCCN, Send StopCCN, idle 2859 not acceptable clean up 2861 wait-ctl-conn Receive SCCRP, Send StopCCN, idle 2862 SCCRQ clean up 2864 established Local open Send control-conn established 2865 request open event to 2866 (new call) waiting sessions 2868 established Administrative Send StopCCN, idle 2869 control-conn clean up 2870 close event 2872 established Receive SCCRQ, Send StopCCN, idle 2873 SCCRP, SCCCN clean up 2875 idle, Receive StopCCN Clean up idle 2876 wait-ctl-reply, 2877 wait-ctl-conn, 2878 established 2880 The states associated with an LCCE for control connection 2881 establishment are as follows: 2883 idle 2884 Both initiator and recipient start from this state. An initiator 2885 transmits an SCCRQ, while a recipient remains in the idle state 2886 until receiving an SCCRQ. 2888 wait-ctl-reply 2889 The originator checks to see if another connection has been 2890 requested from the same peer, and if so, handles the collision 2891 situation described in Section 5.4.3. 2893 wait-ctl-conn 2894 Awaiting an SCCCN. Upon receipt, the challenge response contained 2895 in the message is checked. The control connection is established 2896 if authentication succeeds; otherwise, it is torn down. 2898 established 2899 An established connection may be terminated by either a local 2900 condition or the receipt of a StopCCN. In the event of a local 2901 termination, the originator MUST send a StopCCN and clean up the 2902 control connection. If the originator receives a StopCCN, it MUST 2903 also clean up the control connection. 2905 7.4 Incoming Calls 2907 An ICRQ is generated by an LCCE, typically in response to an incoming 2908 call or a local event. Once the LCCE sends the ICRQ, it waits for a 2909 response from the peer. However, it may choose to postpone 2910 establishment of the call (e.g. answering the call, bringing up the 2911 circuit) until the peer has indicated with an ICRP that it will 2912 accept the call. The peer may choose not to accept the call if, for 2913 instance, there are insufficient resources to handle an additional 2914 session. 2916 If the peer chooses to accept the call, it responds with an ICRP. 2917 When the local LCCE receives the ICRP, it attempts to establish the 2918 call. A final call connected message, the ICCN, is sent from the 2919 local LCCE to the peer to indicate that the call states for both 2920 LCCEs should enter the established state. If the call is terminated 2921 before the peer can accept it, a CDN is sent by the local LCCE to 2922 indicate this condition. 2924 When a call transitions to a "disconnected" or "down" state, the call 2925 is cleared normally, and the local LCCE sends a CDN. Similarly, if 2926 the peer wishes to clear a call, it sends a CDN and cleans up its 2927 session. 2929 7.4.1 ICRQ Sender States 2931 State Event Action New State 2932 ----- ----- ------ --------- 2933 idle Call signal or Initiate local wait-control-conn 2934 ready to receive control-conn 2935 incoming conn open 2937 idle Receive ICCN, Clean up idle 2938 ICRP, CDN 2940 wait-control- Bearer line drop Clean up idle 2941 conn or local close 2942 request 2944 wait-control- control-conn-open Send ICRQ wait-reply 2945 conn 2947 wait-reply Receive ICRP, Send ICCN established 2948 acceptable 2950 wait-reply Receive ICRP, Send CDN, idle 2951 Not acceptable clean up 2953 wait-reply Receive ICRQ Send CDN, idle 2954 clean up 2956 wait-reply Receive CDN, Clean up idle 2957 ICCN 2959 wait-reply Local close Send CDN, idle 2960 request clean up 2962 established Receive CDN Clean up idle 2964 established Receive ICRQ, Send CDN, idle 2965 ICRP, ICCN clean up 2967 established Local close Send CDN, idle 2968 request clean up 2970 The states associated with the ICRQ sender are as follows: 2972 idle 2973 The LCCE detects an incoming call on one of its interfaces (e.g. 2974 an analog PSTN line rings, or an ATM PVC is provisioned), or a 2975 local event occurs. The LCCE initiates its control connection 2976 establishment state machine and moves to a state waiting for 2977 confirmation of the existence of a control connection. 2979 wait-control-connection 2980 In this state, the session is waiting for either the control 2981 connection to be opened or for verification that the control 2982 connection is already open. Once an indication that the control 2983 connection has been opened is received, session control messages 2984 may be exchanged. The first of these messages is the ICRQ. 2986 wait-reply 2987 The ICRQ sender receives either (1) a CDN indicating the peer is 2988 not willing to accept the call (general error or do not accept) 2989 and moves back into the idle state, or (2) an ICRP indicating the 2990 call is accepted. In the latter case, the LCCE sends an ICCN and 2991 enters the established state. 2993 established 2994 Data is exchanged over the session. The call may be cleared by 2995 any of the following: 2996 + An event on the connected interface: The LCCE sends a CDN. 2997 + Receipt of a CDN: The LCCE cleans up, disconnecting the call. 2998 + A local reason: The LCCE sends a CDN. 3000 7.4.2 ICRQ Recipient States 3002 State Event Action New State 3003 ----- ----- ------ --------- 3004 idle Receive ICRQ, Send ICRP wait-connect 3005 acceptable 3007 idle Receive ICRQ, Send CDN, idle 3008 not acceptable clean up 3010 idle Receive ICRP Send CDN idle 3011 clean up 3013 idle Receive ICCN Clean up idle 3015 wait-connect Receive ICCN Prepare for established 3016 acceptable data 3018 wait-connect Receive ICCN Send CDN, idle 3019 not acceptable clean up 3021 wait-connect Receive ICRQ, Send CDN, idle 3022 ICRP clean up 3024 idle, Receive CDN Clean up idle 3025 wait-connect, 3026 established 3028 wait-connect Local close Send CDN, idle 3029 established request clean up 3031 established Receive ICRQ, Send CDN, idle 3032 ICRP, ICCN clean up 3034 The states associated with the ICRQ recipient are as follows: 3036 idle 3037 An ICRQ is received. If the request is not acceptable, a CDN is 3038 sent back to the peer LCCE, and the local LCCE remains in the idle 3039 state. If the ICRQ is acceptable, an ICRP is sent. The session 3040 moves to the wait-connect state. 3042 wait-connect 3043 The local LCCE is waiting for an ICCN from the peer. Upon receipt 3044 of the ICCN, the local LCCE moves to established state. 3046 established 3047 The session is terminated either by sending a CDN or by receiving 3048 a CDN from the peer. Clean up follows on both sides regardless of 3049 the initiator. 3051 7.5 Outgoing Calls 3053 Outgoing calls instruct an LAC to place a call. There are three 3054 messages for outgoing calls: OCRQ, OCRP, and OCCN. An LCCE first 3055 sends an OCRQ to an LAC to request an outgoing call. The LAC MUST 3056 respond to the OCRQ with an OCRP once it determines that the proper 3057 facilities exist to place the call and that the call is 3058 administratively authorized. Once the outbound call is connected, 3059 the LAC sends an OCCN to the peer indicating the final result of the 3060 call attempt. 3062 7.5.1 OCRQ Sender States 3064 State Event Action New State 3065 ----- ----- ------ --------- 3066 idle Local open Initiate local wait-control-conn 3067 request control-conn-open 3069 idle Receive OCCN, Clean up idle 3070 OCRP 3072 wait-control- control-conn-open Send OCRQ wait-reply 3073 conn 3075 wait-reply Receive OCRP, none wait-connect 3076 acceptable 3078 wait-reply Receive OCRP, Send CDN, idle 3079 not acceptable clean up 3081 wait-reply Receive OCCN, Send CDN, idle 3082 OCRQ clean up 3084 wait-connect Receive OCCN none established 3086 wait-connect Receive OCRQ, Send CDN, idle 3087 OCRP clean up 3089 idle, Receive CDN Clean up idle 3090 wait-reply, 3091 wait-connect, 3092 established 3094 established Receive OCRQ, Send CDN, idle 3095 OCRP, OCCN clean up 3097 wait-reply, Local close Send CDN, idle 3098 wait-connect, request clean up 3099 established 3101 wait-control- Local close Clean up idle 3102 conn request 3104 The states associated with the OCRQ sender are as follows: 3106 idle, wait-control-conn 3107 When an outgoing call request is initiated, a control connection 3108 is created as described above, if not already present. Once the 3109 control connection is established, an OCRQ is sent to the LAC, and 3110 the session moves into the wait-reply state. 3112 wait-reply 3113 If a CDN is received, the session is cleaned up and returns to 3114 idle state. If an OCRP is received, the call is in progress, and 3115 the session moves to the wait-connect state. 3117 wait-connect 3118 If a CDN is received, the session is cleaned up and returns to 3119 idle state. If an OCCN is received, the call has succeeded, and 3120 the session may now exchange data. 3122 established 3123 If a CDN is received, the session is cleaned up and returns to 3124 idle state. Alternatively, if the LCCE chooses to terminate the 3125 session, it sends a CDN to the LAC, cleans up the session, and 3126 moves the session to idle state. 3128 7.5.2 OCRQ Recipient (LAC) States 3130 State Event Action New State 3131 ----- ----- ------ --------- 3132 idle Receive OCRQ, Send OCRP, wait-cs-answer 3133 acceptable Place call 3135 idle Receive OCRQ, Send CDN, idle 3136 not acceptable clean up 3138 idle Receive OCRP Send CDN, idle 3139 clean up 3141 idle Receive OCCN, Clean up idle 3142 CDN 3144 wait-cs-answer Call placement Send OCCN established 3145 successful 3147 wait-cs-answer Call placement Send CDN, idle 3148 failed clean up 3150 wait-cs-answer Receive OCRQ, Send CDN, idle 3151 OCRP, OCCN clean up 3153 established Receive OCRQ, Send CDN, idle 3154 OCRP, OCCN clean up 3156 wait-cs-answer, Receive CDN Clean up idle 3157 established 3159 established Local close Send CDN, idle 3160 request clean up 3162 The states associated with the LAC for outgoing calls are as follows: 3164 idle 3165 If the OCRQ is received in error, respond with a CDN. Otherwise, 3166 place the call, send an OCRP, and move to the wait-cs-answer 3167 state. 3169 wait-cs-answer 3170 If the call is not completed or a timer expires while waiting for 3171 the call to complete, send a CDN with the appropriate error 3172 condition set, and go to idle state. If a circuit-switched 3173 connection is established, send an OCCN indicating success, and go 3174 to established state. 3176 established 3177 If the LAC receives a CDN from the peer, the call MUST be released 3178 via appropriate mechanisms, and the session cleaned up. If the 3179 call is disconnected because the circuit transitions to a 3180 "disconnected" or "down" state, the LAC MUST send a CDN to the 3181 peer and return to idle state. 3183 7.6 Termination of a Control Connection 3185 The termination of a control connection consists of either peer 3186 issuing a StopCCN. The sender of this message SHOULD wait a finite 3187 period of time for the acknowledgment of this message before 3188 releasing the control information associated with the control 3189 connection. The recipient of this message should send an 3190 acknowledgment of the message to the peer, then release the 3191 associated control information. 3193 When to release a control connection is an implementation issue and 3194 is not specified in this document. A particular implementation may 3195 use whatever policy is appropriate for determining when to release a 3196 control connection. Some implementations may leave a control 3197 connection open for a period of time or perhaps indefinitely after 3198 the last session for that control connection is cleared. Others may 3199 choose to disconnect the control connection immediately after the 3200 last call on the control connection disconnects. 3202 8. Security Considerations 3204 This section addresses some of the security issues that L2TP 3205 encounters in its operation. 3207 8.1 Control Connection Endpoint Security 3209 The LCCEs may optionally perform an authentication procedure of one 3210 another during control connection establishment. This authentication 3211 has the same security attributes as CHAP and has reasonable 3212 protection against replay and snooping during the control connection 3213 establishment process. This mechanism is not designed to provide any 3214 authentication beyond control connection establishment; it is fairly 3215 simple for a malicious user who can snoop the control connection 3216 stream to inject packets once an authenticated control connection 3217 establishment has been completed successfully. 3219 For authentication to occur, the LCCE pair MUST share a single 3220 secret. Each side uses this same secret when acting as authenticatee 3221 as well as authenticator. Since a single secret is used, the control 3222 connection authentication AVPs include differentiating values in the 3223 CHAP ID fields for each message digest calculation to guard against 3224 replay attacks. 3226 The Assigned Control Connection ID and Assigned Session ID (see 3227 Section 5.4) SHOULD be selected in an unpredictable manner rather 3228 than sequentially or otherwise. Doing so will help deter hijacking 3229 of a session by a malicious user who does not have access to packet 3230 traces between the LCCEs. 3232 The Assigned Cookie value MUST be selected in an unpredictable 3233 manner. However, the Cookie MUST not be regarded as packet-level 3234 authentication or security of any kind. It should be used for 3235 nothing more than simple configuration error detection and 3236 identification of misrouted packets. Since the Cookie is sent and 3237 advertised in the clear, it is by no means a true packet-level 3238 security measure, such as that offered by IPsec. 3240 8.2 Packet-Level Security 3242 Securing L2TP requires that the underlying transport make available 3243 encryption, integrity, and authentication services for all L2TP 3244 traffic. This secure transport operates on the entire L2TP packet 3245 and is functionally independent of the data being carried on an L2TP 3246 data session. As such, L2TP is only concerned with confidentiality, 3247 authenticity, and integrity of the L2TP packets between two LCCEs, 3248 not unlike link layer encryption being concerned only about 3249 protecting the confidentiality of traffic between the physical 3250 endpoints. 3252 8.3 End-to-End Security 3254 Protecting the L2TP packet stream via a secure transport does, in 3255 turn, also protect the data within the tunneled session packets while 3256 transported from one LCCE to the other. Such protection should not 3257 be considered a substitution for end-to-end security between 3258 communicating hosts or applications. 3260 8.4 L2TP and IPsec 3262 When running over IP, IPsec provides packet-level security via ESP 3263 [RFC3193]. All L2TP control and data packets for a particular 3264 control connection appear as homogeneous UDP/IP data packets to the 3265 IPsec system. 3267 In addition to IP transport security, IPsec defines a mode of 3268 operation that allows tunneling of IP packets. The packet-level 3269 encryption and authentication provided by IPsec tunnel mode and that 3270 provided by L2TP secured with IPsec provide an equivalent level of 3271 security for these requirements. 3273 IPsec also defines access control features that are required of a 3274 compliant IPsec implementation. These features allow filtering of 3275 packets based upon network and transport layer characteristics such 3276 as IP address, ports, etc. In the L2TP tunneling model, analogous 3277 filtering is logically performed at the network layer above L2TP. 3278 These network layer access control features may be handled at an LCCE 3279 via vendor-specific authorization features based upon the 3280 authenticated user, or at the network layer itself by using IPsec 3281 transport mode end-to-end between the communicating hosts. The 3282 requirements for access control mechanisms are not a part of the L2TP 3283 specification and as such are outside the scope of this document. 3285 8.5 Impact of L2TPv3 Features on RFC 3193 3287 [RFC3193] defines the recommended method for securing L2TP as defined 3288 in [RFC2661]. L2TP as defined in this document should possess the 3289 same interface to IPsec as [RFC2661] when running on UDP/IP. UDP has 3290 the added advantage of being able to provide a native method for 3291 IPsec to distinguish multiple Security Associations (presumably with 3292 different policies) between the same control connection endpoints 3293 without having to extend the definitions of IPsec or allocate 3294 additional IP addresses between endpoints. Therefore, when securing 3295 L2TP with IPsec via [RFC3193], L2TPv3 MUST operate over UDP/IP as 3296 described in Section 4.1.2. 3298 9. IANA Considerations 3300 This document defines a number of "magic" numbers to be maintained by 3301 the IANA. This section explains the criteria to be used by the IANA 3302 to assign additional numbers in each of these lists. The following 3303 subsections describe the assignment policy for the namespaces defined 3304 elsewhere in this document. 3306 9.1 AVP Attributes 3308 As defined in Section 5.1, AVPs contain Vendor ID, Attribute, and 3309 Value fields. For a Vendor ID value of 0, IANA will maintain a 3310 registry of assigned Attributes and, in some cases, Values. 3311 Attributes 0-39 are assigned as defined in Section 5.4. The 3312 remaining values are available for assignment upon Expert Review 3314 [RFC2434]. 3316 9.2 Message Type AVP Values 3318 As defined in Section 5.4.1, Message Type AVPs (Attribute Type 0) 3319 have an associated value maintained by IANA. Values 0-16 are defined 3320 in Section 3.1. The remaining values are available for assignment 3321 upon Expert Review [RFC2434]. 3323 9.3 Result Code AVP Values 3325 As defined in Section 5.4.2, Result Code AVPs (Attribute Type 1) 3326 contain three fields. Two of these fields (the Result Code and Error 3327 Code fields) have associated values maintained by IANA. 3329 9.3.1 Result Code Field Values 3331 The Result Code AVP may be included in CDN and StopCCN messages. The 3332 allowable values for the Result Code field of the AVP differ 3333 depending upon the value of the Message Type AVP. For the StopCCN 3334 message, values 0-7 are defined in Section 5.4.2; for the CDN 3335 message, values 0-11 are defined in the same section. The remaining 3336 values of the Result Code field for both messages are available for 3337 assignment upon Expert Review [RFC2434]. 3339 9.3.2 Error Code Field Values 3341 Values 0-9 are defined in Section 5.4.2. The remaining values are 3342 available for assignment upon Expert Review [RFC2434]. 3344 9.4 AVP Header Bits 3346 There are four remaining reserved bits in the AVP header. Additional 3347 bits should only be assigned via a Standards Action [RFC2434]. 3349 9.5 L2TP Control Message Header Bits 3351 There are nine remaining reserved bits in the control message header. 3352 Additional bits should only be assigned via a Standards Action 3353 [RFC2434]. 3355 Care should be taken before using reserved bits 6 and 7 in the L2TPv3 3356 control message header since these bits have meaning for L2TPv2 data 3357 messages. Using these two bits in L2TPv3 MAY trigger an unforeseen 3358 interoperability problem with L2TPv3 implementations based on L2TPv2. 3359 Therefore, it is recommended that these two bits be utilized last, 3360 after the other reserved bits have been assigned roles. 3362 10. References 3364 [DSS1] ITU-T Recommendation, "Digital subscriber Signaling System 3365 No. 1 (DSS 1) - ISDN user-network interface layer 3 3366 specification for basic call control", Rec. Q.931(I.451), 3367 May 1998. 3369 [KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network 3370 Security: Private Communications in a Public World", 3371 Prentice Hall, March 1995, ISBN 0-13-061466-1. 3373 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3374 September 1981. 3376 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 3377 STD 13, RFC 1034, November 1987. 3379 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed 3380 Serial Links", RFC 1144, February 1990. 3382 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 3383 RFC 1661, July 1994. 3385 [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, 3386 July 1994. 3388 [RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994. 3390 [RFC1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, 3391 RFC 1700, October 1994. See also: 3392 http://www.iana.org/numbers.html. 3394 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and 3395 Coradetti, T., "The PPP Multilink Protocol (MP)", RFC 1990, 3396 August 1996. 3398 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 3399 Protocol (CHAP)", RFC 1994, August 1996. 3401 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 3402 and Lear, E., "Address Allocation for Private Internets", 3403 BCP 5, RFC 1918, February 1996. 3405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3406 Requirement Levels", BCP 14, RFC 2119, March 1997. 3408 [RFC2138] Rigney, C., Rubens, A., Simpson, W., and Willens, S., 3409 "Remote Authentication Dial In User Service (RADIUS)", 3410 RFC 2138, April 1997. 3412 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 3413 Languages", BCP 18, RFC 2277, January 1998. 3415 [RFC2341] Valencia, A., Littlewood, M., and Kolar, T., 3416 "Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341, 3417 May 1998. 3419 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 3420 Internet Protocol", RFC 2401, November 1998. 3422 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3423 IANA Considerations section in RFCs", BCP 26, RFC 2434, 3424 October 1998. 3426 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., 3427 and Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", 3428 RFC 2637, July 1999. 3430 [RFC2661] Townsley, W., et al., "Layer Two Tunneling Layer Two Tunneling 3431 Protocol (L2TP)", RFC 2661, August 1999. 3433 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Finland, T., Armitage, G., 3434 and Malis, A., "A Framework for IP Based Virtual Private 3435 Networks", RFC 2764, February 2000. 3437 [RFC2809] Aboba, B., and Zorn, G., "Implementation of L2TP Compulsory 3438 Tunneling via RADIUS", RFC 2809, April 2000. 3440 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and Booth, S., 3441 "Securing L2TP using IPsec", RFC 3193, November 2001. 3443 [RFC3070] Rawat, V., Tio, R., Nanji, S., and Verma, R., 3444 "Layer Two Tunneling Protocol (L2TP) over Frame Relay", 3445 RFC 3070, February 2001. 3447 [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I: The 3448 Protocols", Addison-Wesley Publishing Company, Inc., 3449 March 1996, ISBN 0-201-63346-9. 3451 [L2TPAAL5] Davison, M., Lin, A., Singh, A., Stephens, J., Turner, R., 3452 Tio, R., and Nanji, S., "L2TP Over AAL5," Internet Draft, 3453 August 2001, draft-ietf-l2tpext-l2tp-atm-02.txt. 3455 11. Editors' Addresses 3457 Jed Lau 3458 cisco Systems 3459 170 W. Tasman Drive 3460 San Jose, CA 95134 3461 jedlau@cisco.com 3463 Gurdeep Singh Pall 3464 Microsoft Corporation 3465 Redmond, WA 3466 gurdeep@microsoft.com 3468 Bill Palter 3469 RedBack Networks, Inc 3470 1389 Moffett Park Drive 3471 Sunnyvale, CA 94089 3472 palter@zev.net 3474 Allan Rubens 3475 acr@del.com 3477 W. Mark Townsley 3478 cisco Systems 3479 7025 Kit Creek Road 3480 PO Box 14987 3481 Research Triangle Park, NC 27709 3482 mark@townsley.net 3484 Andrew J. Valencia 3485 P.O. Box 2928 3486 Vashon, WA 98070 3487 vandys@zendo.com 3489 Glen Zorn 3490 cisco Systems 3491 500 108th Avenue N.E., Suite 500 3492 Bellevue, WA 98004 3493 gwz@cisco.com 3495 Appendix A: Control Slow Start and Congestion Avoidance 3497 Although each side has indicated the maximum size of its receive 3498 window, it is recommended that a slow start and congestion avoidance 3499 method be used to transmit control packets. The methods described 3500 here are based upon the TCP congestion avoidance algorithm as 3501 described in section 21.6 of TCP/IP Illustrated, Volume I, by 3502 W. Richard Stevens [STEVENS]. 3504 Slow start and congestion avoidance make use of several variables. The 3505 congestion window (CWND) defines the number of packets a sender may send 3506 before waiting for an acknowledgment. The size of CWND expands and 3507 contracts as described below. Note, however, that CWND is never allowed to 3508 exceed the size of the advertised window obtained from the Receive Window 3509 AVP. (In the text below, it is assumed any increase will be limited by the 3510 Receive Window Size.) The variable SSTHRESH determines when the sender 3511 switches from slow start to congestion avoidance. Slow start is used while 3512 CWND is less than SSHTRESH. 3514 A sender starts out in the slow start phase. CWND is initialized to one 3515 packet, and SSHTRESH is initialized to the advertised window (obtained from 3516 the Receive Window AVP). The sender then transmits one packet and waits 3517 for its acknowledgment (either explicit or piggybacked). When the 3518 acknowledgment is received, the congestion window is incremented from one 3519 to two. During slow start, CWND is increased by one packet each time an 3520 ACK (explicit ZLB or piggybacked) is received. Increasing CWND by one on 3521 each ACK has the effect of doubling CWND with each round trip, resulting in 3522 an exponential increase. When the value of CWND reaches SSHTRESH, the slow 3523 start phase ends and the congestion avoidance phase begins. 3525 During congestion avoidance, CWND expands more slowly. Specifically, 3526 it increases by 1/CWND for every new ACK received. That is, CWND is 3527 increased by one packet after CWND new ACKs have been received. 3528 Window expansion during the congestion avoidance phase is effectively 3529 linear, with CWND increasing by one packet each round trip. 3531 When congestion occurs (indicated by the triggering of a retransmission) 3532 one-half of the CWND is saved in SSTHRESH, and CWND is set to one. The 3533 sender then reenters the slow start phase. 3535 Appendix B: Control Message Examples 3537 B.1: Lock-Step Control Connection Establishment 3539 In this example, an LCCE establishes a control connection, with the 3540 exchange involving each side alternating in sending messages. This example 3541 shows the final acknowledgment explicitly sent within a ZLB ACK message. 3542 An alternative would be to piggyback the acknowledgment within a message 3543 sent as a reply to the ICRQ or OCRQ that will likely follow from the side 3544 that initiated the control connection. 3546 LCCE A LCCE B 3547 ------ ------ 3548 SCCRQ -> 3549 Nr: 0, Ns: 0 3550 <- SCCRP 3551 Nr: 1, Ns: 0 3552 SCCCN -> 3553 Nr: 1, Ns: 1 3554 <- ZLB 3555 Nr: 2, Ns: 1 3557 B.2: Lost Packet with Retransmission 3559 An existing control connection has a new session requested by LCCE A. 3560 The ICRP is lost and must be retransmitted by LCCE B. Note that loss 3561 of the ICRP has two effects: It not only keeps the upper level state 3562 machine from progressing, but also keeps LCCE A from seeing a timely 3563 lower level acknowledgment of its ICRQ. 3565 LCCE A LCCE B 3566 ------ ------ 3567 ICRQ -> 3568 Nr: 1, Ns: 2 3569 (packet lost) <- ICRP 3570 Nr: 3, Ns: 1 3572 (pause; LCCE A's timer started first, so fires first) 3574 ICRQ -> 3575 Nr: 1, Ns: 2 3577 (Realizing that it has already seen this packet, 3578 LCCE B discards the packet and sends a ZLB) 3580 <- ZLB 3581 Nr: 3, Ns: 2 3583 (LCCE B's retransmit timer fires) 3585 <- ICRP 3586 Nr: 3, Ns: 1 3587 ICCN -> 3588 Nr: 2, Ns: 3 3590 <- ZLB 3591 Nr: 4, Ns: 2 3593 Appendix C: Intellectual Property Notice 3595 The IETF takes no position regarding the validity or scope of any 3596 intellectual property or other rights that might be claimed to 3597 pertain to the implementation or use of the technology described in 3598 this document or the extent to which any license under such rights 3599 might or might not be available; neither does it represent that it 3600 has made any effort to identify any such rights. Information on the 3601 IETF's procedures with respect to rights in standards-track and 3602 standards-related documentation can be found in BCP-11. Copies of 3603 claims of rights made available for publication and any assurances of 3604 licenses to be made available, or the result of an attempt made to 3605 obtain a general license or permission for the use of such 3606 proprietary rights by implementers or users of this specification can 3607 be obtained from the IETF Secretariat. 3609 The IETF invites any interested party to bring to its attention any 3610 copyrights, patents or patent applications, or other proprietary 3611 rights that may cover technology that may be required to practice 3612 this standard. Please address the information to the IETF Executive 3613 Director. 3615 The IETF has been notified of intellectual property rights claimed in 3616 regard to some or all of the specification contained in this 3617 document. For more information consult the online list of claimed 3618 rights. 3620 Appendix D: Full Copyright Statement 3622 Copyright (C) The Internet Society (2002). All Rights Reserved. 3624 This document and translations of it may be copied and furnished to 3625 others, and derivative works that comment on or otherwise explain it 3626 or assist in its implementation may be prepared, copied, published 3627 and distributed, in whole or in part, without restriction of any 3628 kind, provided that the above copyright notice and this paragraph are 3629 included on all such copies and derivative works. However, this 3630 document itself may not be modified in any way, such as by removing 3631 the copyright notice or references to the Internet Society or other 3632 Internet organizations, except as needed for the purpose of 3633 developing Internet standards in which case the procedures for 3634 copyrights defined in the Internet Standards process must be 3635 followed, or as required to translate it into languages other than 3636 English. 3638 The limited permissions granted above are perpetual and will not be 3639 revoked by the Internet Society or its successors or assigns. 3641 This document and the information contained herein is provided on an 3642 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3643 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3644 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3645 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3646 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.