idnits 2.17.00 (12 Aug 2021) /tmp/idnits54368/draft-ietf-l2tpext-l2tp-base-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 87 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 88 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == 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 3115 has weird spacing: '...eptable conn...' == Line 3122 has weird spacing: '...breaker los...' == Line 3127 has weird spacing: '...ol-conn est...' == Line 3137 has weird spacing: '...ol-conn est...' == Line 3207 has weird spacing: '...e local wai...' == (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, 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. -- 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 (October 2003) is 6792 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3438' is mentioned on line 3651, but not defined == Missing Reference: 'RFC2890' is mentioned on line 4063, but not defined == Unused Reference: 'RFC1994' is defined on line 3795, but no explicit reference was found in the text == Unused Reference: 'RFC2138' is defined on line 3849, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1958 ** Downref: Normative reference to an Informational RFC: RFC 2072 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) -- Obsolete informational reference (is this intentional?): RFC 1700 (Obsoleted by RFC 3232) -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2138 (Obsoleted by RFC 2865) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) Summary: 7 errors (**), 0 flaws (~~), 15 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Lau 2 Internet-Draft M. Townsley 3 Category: Standards Track cisco Systems 4 I. Goyret 5 Lucent Technologies 6 Editors 7 October 2003 9 Layer Two Tunneling Protocol (Version 3) 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes "version 3" of the Layer Two Tunneling 39 Protocol (L2TPv3). L2TPv3 defines the base control protocol and 40 encapsulation for tunneling multiple layer 2 connections between two 41 IP connected nodes. Additional documents detail the specifics for 42 each link-type being emulated. 44 Contents 46 Status of this Memo.......................................... 1 48 1. Introduction............................................. 4 49 1.1 Changes from RFC 2661................................ 5 50 1.2 Specification of Requirements........................ 5 51 1.3 Terminology.......................................... 5 53 2. Topology................................................. 9 55 3. Protocol Overview........................................ 10 56 3.1 Control Message Types................................ 11 57 3.2 L2TP Header Formats.................................. 12 58 3.2.1 L2TP Control Message Header..................... 12 59 3.2.2 L2TP Data Message............................... 13 60 3.3 Control Connection Management........................ 14 61 3.3.1 Control Connection Establishment................ 15 62 3.3.2 Control Connection Teardown..................... 15 63 3.4 Session Management................................... 16 64 3.4.1 Session Establishment for an Incoming Call...... 16 65 3.4.2 Session Establishment for an Outgoing Call...... 16 66 3.4.3 Session Teardown................................ 16 68 4. Protocol Operation....................................... 17 69 4.1 L2TP Over Specific Packet-Switched Networks (PSN).... 17 70 4.1.1 L2TPv3 over IP.................................. 18 71 4.1.2 L2TP over UDP................................... 19 72 4.1.3 IP Fragmentation Issues......................... 21 73 4.2 Reliable Delivery of Control Messages................ 21 74 4.3 Control Connection and Control Message Authentication 23 75 4.4 Keepalive (Hello).................................... 24 76 4.5 Forwarding Session Data Frames....................... 25 77 4.6 Default L2-Specific Sublayer......................... 25 78 4.6.1 Sequencing Data Packets......................... 26 79 4.7 L2TPv2/v3 Interoperability and Migration............. 27 80 4.7.1 L2TPv3 over IP.................................. 27 81 4.7.2 L2TPv3 over UDP................................. 27 82 4.7.3 Automatic L2TPv2 Fallback....................... 28 84 5. Control Message Attribute Value Pairs.................... 28 85 5.1 AVP Format........................................... 28 86 5.2 Mandatory AVPs and Setting the M Bit................. 30 87 5.3 Hiding of AVP Attribute Values....................... 31 88 5.4 AVP Summary.......................................... 33 89 5.4.1 General Control Message AVPs.................... 33 90 5.4.2 Result and Error Codes.......................... 37 91 5.4.3 Control Connection Management AVPs.............. 40 92 5.4.4 Session Management AVPs......................... 45 93 5.4.5 Circuit Status AVPs............................. 53 95 6. Control Connection Protocol Specification................ 56 96 6.1 Start-Control-Connection-Request (SCCRQ)............. 56 97 6.2 Start-Control-Connection-Reply (SCCRP)............... 56 98 6.3 Start-Control-Connection-Connected (SCCCN)........... 57 99 6.4 Stop-Control-Connection-Notification (StopCCN)....... 57 100 6.5 Hello (HELLO)........................................ 58 101 6.6 Incoming-Call-Request (ICRQ)......................... 58 102 6.7 Incoming-Call-Reply (ICRP)........................... 59 103 6.8 Incoming-Call-Connected (ICCN)....................... 59 104 6.9 Outgoing-Call-Request (OCRQ)......................... 60 105 6.10 Outgoing-Call-Reply (OCRP).......................... 61 106 6.11 Outgoing-Call-Connected (OCCN)...................... 61 107 6.12 Call-Disconnect-Notify (CDN)........................ 62 108 6.13 WAN-Error-Notify (WEN).............................. 62 109 6.14 Set-Link-Info (SLI)................................. 63 110 6.15 Explicit-Acknowledgement (ACK)...................... 63 112 7. Control Connection State Machines........................ 64 113 7.1 Malformed Control Messages........................... 64 114 7.2 Control Connection States............................ 65 115 7.3 Incoming Calls....................................... 67 116 7.3.1 ICRQ Sender States.............................. 68 117 7.3.2 ICRQ Recipient States........................... 69 118 7.4 Outgoing Calls....................................... 70 119 7.4.1 OCRQ Sender States.............................. 71 120 7.4.2 OCRQ Recipient (LAC) States..................... 72 121 7.5 Termination of a Control Connection.................. 73 123 8. Security Considerations.................................. 74 124 8.1 Control Connection Endpoint and Message Security..... 74 125 8.2 Data Channel Security................................ 74 126 8.3 End-to-End Security.................................. 75 127 8.4 L2TP and IPsec....................................... 75 128 8.5 Impact of L2TPv3 Features on RFC 3193................ 75 130 9. Internationalization Considerations...................... 76 132 10. IANA Considerations..................................... 76 133 10.1 Control Message Attribute Value Pairs (AVPs)........ 76 134 10.2 Message Type AVP Values............................. 77 135 10.3 Result Code AVP Values.............................. 77 136 10.3.2 Error Code Field Values........................ 77 137 10.4 AVP Header Bits..................................... 77 138 10.5 L2TP Control Message Header Bits.................... 77 139 10.6 Pseudowire Types..................................... 78 140 10.7 Application Code..................................... 78 141 10.8 Circuit Status Bits.................................. 78 142 10.9 Default L2-Specific Sublayer bits.................... 78 143 10.10 L2-Specific Sublayer Type........................... 78 144 10.11 Data Sequencing Level............................... 79 146 13. Acknowledgments......................................... 79 148 11. References.............................................. 80 149 11.1 Normative References................................ 80 150 11.2 Informative References.............................. 81 152 12. Editors' Addresses...................................... 82 154 Appendix A: Control Slow Start and Congestion Avoidance...... 82 156 Appendix B: Control Message Examples......................... 83 158 Appendix C: Processing Sequence Numbers...................... 85 160 Appendix D: Intellectual Property Notice..................... 87 162 Appendix E: Full Copyright Statement......................... 87 164 1. Introduction 166 The Layer Two Tunneling Protocol (L2TP) provides a dynamic mechanism 167 for tunneling Layer 2 (L2) "circuits" across a packet-oriented data 168 network (e.g., over IP). L2TP, as originally defined in RFC 2661, is 169 a standard method for tunneling Point to Point Protocol (PPP) 170 [RFC1661] sessions. L2TP has since been adopted for tunneling a 171 number of other L2 protocols. In order to provide greater 172 modularity, this document describes the base L2TP protocol, 173 independent of the L2 payload that is being tunneled. 175 The base L2TP protocol defined in this document consists of (1) the 176 control protocol for dynamic creation, maintenance, and teardown of 177 L2TP sessions, and (2) the L2TP data encapsulation to multiplex and 178 demultiplex L2 data streams between two L2TP nodes across an IP 179 network. Additional documents are expected to be published for each 180 layer 2 data link emulation type (a.k.a. pseudowire-type) supported 181 by L2TP (i.e., PPP, Ethernet, Frame Relay, etc.). These documents 182 will contain any individual details that are outside the scope of 183 this base specification. 185 1.1 Changes from RFC 2661 187 Many of the protocol constructs described in this document are 188 carried over from RFC 2661. Changes include clarifications based on 189 years of interoperability and deployment experience as well as 190 modifications to either improve protocol operation or provide a 191 clearer separation from PPP. The intent of these modifications is to 192 achieve a healthy balance between code reuse, interoperability 193 experience, and a directed evolution of L2TP as it is applied to new 194 tasks. 196 When the designation between L2TPv2 and L2TPv3 is necessary, L2TP as 197 defined in RFC 2661 will be referred to as "L2TPv2", corresponding to 198 the value in the Version field of an L2TP header. (Layer 2 199 Forwarding, L2F, [RFC2341] was defined as "version 1".) At times, 200 L2TP as defined in this document will be referred to as "L2TPv3". 201 Otherwise, the acronym "L2TP" will refer to L2TPv3 or L2TP in 202 general. 204 Notable differences between L2TPv2 and L2TPv3 include: 206 Separation of all PPP-related AVPs, references, etc., including a 207 portion of the L2TP data header that was specific to the needs of 208 PPP. The PPP-specific constructs are described in a companion 209 document. 211 Transition from a 16-bit Session ID and Tunnel ID to a 32-bit 212 Session ID and Control Connection ID, respectively. 214 Extension of the Tunnel Authentication mechanism to cover the 215 entire control message rather than just a portion of certain 216 messages. 218 Details of these changes and a recommendation for transitioning to 219 L2TPv3 may be found in Section 4.7. 221 1.2 Specification of Requirements 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 225 document are to be interpreted as described in [RFC2119]. 227 1.3 Terminology 229 Attribute Value Pair (AVP) 231 The variable-length concatenation of a unique Attribute 232 (represented by an integer), a length field, and a Value 233 containing the actual value identified by the attribute. Zero or 234 more AVPs make up the body of control messages, which are used in 235 the establishment, maintenance, and teardown of control 236 connections. This basic construct is sometimes referred to as a 237 Type-Length-Value (TLV) in some specifications. (See also: 238 Control Connection, Control Message.) 240 Call (Circuit Up) 242 The action of transitioning a circuit on an L2TP Access 243 Concentrator (LAC) to an "up" or "active" state. A call may be 244 dynamically established through signaling properties (e.g., an 245 incoming or outgoing call through the Public Switched Telephone 246 Network (PSTN)) or statically configured (e.g., provisioning a 247 Virtual Circuit on an interface). A call is defined by its 248 properties (e.g., type of call, called number, etc.) and its data 249 traffic. (See also: Circuit, Session, Incoming Call, Outgoing 250 Call, Outgoing Call Request.) 252 Circuit 254 A general term identifying any one of a wide range of L2 255 connections. A circuit may be virtual in nature (e.g., an ATM 256 PVC, an ethernet VLAN, or an L2TP session), or it may have direct 257 correlation to a physical layer (e.g., an RS-232 serial line). 258 Circuits may be statically configured with a relatively long-lived 259 uptime, or dynamically established with signaling to govern the 260 establishment, maintenance, and teardown of the circuit. For the 261 purposes of this document, a statically configured circuit is 262 considered to be essentially the same as a very simple, long- 263 lived, dynamic circuit. (See also: Call, Remote System.) 265 Client 267 (See Remote System.) 269 Control Connection 271 An L2TP control connection is a reliable control channel that is 272 used to establish, maintain, and release individual L2TP sessions 273 as well as the control connection itself. (See also: Control 274 Message, Data Channel.) 276 Control Message 278 An L2TP message used by the control connection. (See also: 279 Control Connection.) 281 Data Message 283 Message used by the data channel. (a.k.a. Data Packet, See also: 284 Data Channel.) 286 Data Channel 288 The channel for L2TP-encapsulated data traffic that passes between 289 two LCCEs over a Packet Switched Network (i.e. IP). (See also: 290 Control Connection, Data Message.) 292 Incoming Call 294 The action of receiving a call (circuit up event) on an LAC. The 295 call may have been placed by a remote system (e.g., a phone call 296 over a PSTN), or it may have been triggered by a local event 297 (e.g., interesting traffic routed to a virtual interface). An 298 incoming call that needs to be tunneled (as determined by the LAC) 299 results in the generation of an L2TP ICRQ message. (See also: 300 Call, Outgoing Call, Outgoing Call Request.) 302 L2TP Access Concentrator (LAC) 304 If an L2TP Control Connection Endpoint (LCCE) is being used to 305 cross-connect an L2TP session directly to a data link, we refer to 306 it as an L2TP Access Concentrator (LAC). An LCCE may act as both 307 an L2TP Network Server (LNS) for some sessions and an LAC for 308 others, so these terms must only be used within the context of a 309 given set of sessions unless the LCCE is in fact single purpose 310 for a given topology. (See also: LCCE, LNS.) 312 L2TP Control Connection Endpoint (LCCE) 314 An L2TP node which exists at either end of an L2TP control 315 connection. May also be referred to as an LAC or LNS, depending on 316 whether tunneled frames are processed at the data link (LAC) or 317 network layer (LNS). (See also: LAC, LNS.) 319 L2TP Network Server (LNS) 321 If a given L2TP session is terminated at the L2TP node and the 322 encapsulated network layer (L3) packet processed on a virtual 323 interface, we refer to this L2TP node as an L2TP Network Server 324 (LNS). A given LCCE may act as both an LNS for some sessions and 325 an LAC for others, so these terms must only be used within the 326 context of a given set of sessions unless the LCCE is in fact 327 single purpose for a given topology. (See also: LCCE, LAC.) 329 Outgoing Call 331 The action of placing a call by an LAC, typically in response to 332 policy directed by the peer in an Outgoing Call Request message. 333 (See also: Call, Incoming Call, Outgoing Call Request.) 335 Outgoing Call Request 337 A request sent to an LAC to place an outgoing call. The request 338 contains specific information not known a priori by the LAC (i.e., 339 a number to dial). (See also: Call, Incoming Call, Outgoing 340 Call.) 342 Packet-Switched Network (PSN) 344 A network that uses packet-switching technology for data delivery. 345 For L2TPv3, this layer is principally IP. Other examples include 346 MPLS, Frame Relay, and ATM. 348 Peer 350 When used in context with L2TP, Peer refers to the far end of an 351 L2TP control connection (i.e., the remote LCCE). An LAC's peer 352 may be either an LNS or another LAC. Similarly, an LNS's peer may 353 be either an LAC or another LNS. (See also: LAC, LCCE, LNS.) 355 Pseudowire (PW) 357 An emulated circuit as it traverses a PSN. There is one 358 Pseudowire per L2TP Session. (See also: Packet-Switched Network, 359 Session.) 361 Pseudowire Type 363 The payload type being carried within an L2TP session. Examples 364 include PPP, Ethernet, and Frame Relay. (See also: Session.) 366 Remote System 368 An end-system or router connected by a circuit to an LAC. 370 Session 372 An L2TP session is the entity which is created between two LCCEs 373 in order to exchange parameters for and maintain an emulated L2 374 connection. Multiple sessions may be associated with a single 375 Control Connection. 377 Zero-Length Body (ZLB) Message 379 A control message with only an L2TP header. ZLB messages are used 380 only to acknowledge messages on the L2TP reliable control channel. 381 (See also: Control Message.) 383 2. Topology 385 L2TP operates between two L2TP Control Connection Endpoints (LCCEs), 386 tunneling traffic across a packet network. There are three 387 predominant tunneling models in which L2TP operates: LAC-LNS (or vice 388 versa), LAC-LAC, and LNS-LNS. These models are diagrammed below. 389 (Dotted lines designate network connections. Solid lines designate 390 circuit connections.) 392 Figure 2.0: L2TP Reference Models 394 (a) LAC-LNS Reference Model: On one side, the LAC receives traffic 395 from an L2 circuit, which it forwards via L2TP across an IP or other 396 packet-based network. On the other side, an LNS logically terminates 397 the L2 circuit locally and routes network traffic to the home 398 network. The action of session establishment is driven by the LAC 399 (as an incoming call) or the LNS (as an outgoing call). 401 +-----+ L2 +-----+ +-----+ 402 | |------| LAC |.........[ IP ].........| LNS |...[home network] 403 +-----+ +-----+ +-----+ 404 remote 405 system 406 |<-- emulated service -->| 407 |<----------- L2 service ------------>| 409 (b) LAC-LAC Reference Model: In this model, both LCCEs are LACs. 410 Each LAC forwards circuit traffic from the remote system to the peer 411 LAC using L2TP, and vice versa. In its simplest form, an LAC acts as 412 a simple cross-connect between a circuit to a remote system and an 413 L2TP session. This model typically involves symmetric establishment; 414 that is, either side of the connection may initiate a session at any 415 time (or simultaneously, in which a tie-breaking mechanism is 416 utilized). 418 +-----+ L2 +-----+ +-----+ L2 +-----+ 419 | |------| LAC |........[ IP ]........| LAC |------| | 420 +-----+ +-----+ +-----+ +-----+ 421 remote remote 422 system system 423 |<- emulated service ->| 424 |<----------------- L2 service ----------------->| 426 (c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs. A 427 user-level, traffic-generated, or signaled event typically drives 428 session establishment from one side of the tunnel. For example, a 429 tunnel generated from a PC by a user, or automatically by customer 430 premises equipment. 432 +-----+ +-----+ 433 [home network]...| LNS |........[ IP ]........| LNS |...[home network] 434 +-----+ +-----+ 435 |<- emulated service ->| 436 |<---- L2 service ---->| 438 Note: In L2TPv2, user-driven tunneling of this type is often referred 439 to as "voluntary tunneling" [RFC2809]. Further, an LNS acting as part 440 of a software package on a host is sometimes referred to as an "LAC 441 Client" [RFC2661]. 443 3. Protocol Overview 445 L2TP utilizes two types of messages, control messages and data 446 messages (sometimes referred to as "control packets" and "data 447 packets", respectively). Control messages are used in the 448 establishment, maintenance, and clearing of control connections and 449 sessions. These messages utilize a reliable control channel within 450 L2TP to guarantee delivery (see Section 4.2 for details). Data 451 messages are used to encapsulate the L2 traffic being carried over 452 the L2TP session. Unlike control messages, data messages are not 453 retransmitted when packet loss occurs. 455 The L2TPv3 control message format defined in this document borrows 456 largely from L2TPv2. These control messages are used in conjunction 457 with the associated protocol state machines that govern the dynamic 458 setup, maintenance, and teardown for L2TP sessions. The data message 459 format for tunneling data packets may be utilized with or without the 460 L2TP control channel, either via manual configuration or other 461 signaling methods to pre-configure or distribute L2TP session 462 information. Utilization of the L2TP data message format with other 463 signaling methods is outside the scope of this document. 465 Figure 3.0: L2TPv3 Structure 467 +-------------------+ +-----------------------+ 468 | Tunneled Frame | | L2TP Control Message | 469 +-------------------+ +-----------------------+ 470 | L2TP Data Header | | L2TP Control Header | 471 +-------------------+ +-----------------------+ 472 | L2TP Data Channel | | L2TP Control Channel | 473 | (unreliable) | | (reliable) | 474 +-------------------+----+-----------------------+ 475 | Packet-Switched Network (IP, FR, MPLS, etc.) | 476 +------------------------------------------------+ 478 Figure 3.0 depicts the relationship of control messages and data 479 messages over the L2TP control and data channels, respectively. Data 480 messages are passed over an unreliable data channel, encapsulated by 481 an L2TP header, and sent over a Packet-Switched Network (PSN) such as 482 IP, UDP, Frame Relay, ATM, MPLS, etc. Control messages are sent over 483 a reliable L2TP control channel, which operates over the same PSN. 485 The necessary setup for tunneling a session with L2TP consists of two 486 steps: (1) Establishing the control connection, and (2) establishing 487 a session as triggered by an incoming call or outgoing call. An L2TP 488 session MUST be established before L2TP can begin to forward session 489 frames. Multiple sessions may be bound to a single control 490 connection, and multiple control connections may exist between the 491 same two LCCEs. 493 3.1 Control Message Types 495 The Message Type AVP (see Section 5.4.1) defines the specific type of 496 control message being sent. 498 This document defines the following control message types (see 499 Sections 6.1 through 6.13 for details on the construction and use of 500 each message): 502 Control Connection Management 504 0 (reserved) 505 1 (SCCRQ) Start-Control-Connection-Request 506 2 (SCCRP) Start-Control-Connection-Reply 507 3 (SCCCN) Start-Control-Connection-Connected 508 4 (StopCCN) Stop-Control-Connection-Notification 509 5 (reserved) 510 6 (HELLO) Hello 511 TBA-M1 (ACK) Explicit Acknowledgement 513 Call Management 515 7 (OCRQ) Outgoing-Call-Request 516 8 (OCRP) Outgoing-Call-Reply 517 9 (OCCN) Outgoing-Call-Connected 518 10 (ICRQ) Incoming-Call-Request 519 11 (ICRP) Incoming-Call-Reply 520 12 (ICCN) Incoming-Call-Connected 521 13 (reserved) 522 14 (CDN) Call-Disconnect-Notify 524 Error Reporting 526 15 (WEN) WAN-Error-Notify 528 Link Status Change Reporting 530 16 (SLI) Set-Link-Info 532 3.2 L2TP Header Formats 534 This section defines header formats for L2TP control messages and 535 L2TP data messages. All values are placed into their respective 536 fields and sent in network order (high-order octets first). 538 3.2.1 L2TP Control Message Header 540 The L2TP control message header provides information for the reliable 541 transport of messages that govern the establishment, maintenance, and 542 teardown of L2TP sessions. By default, control messages are sent 543 over the underlying media in-band with L2TP data messages. 545 The L2TP control message header is formatted as follows: 547 Figure 3.2.1: L2TP Control Message Header 549 0 1 2 3 550 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 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 |T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Control Connection ID | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Ns | Nr | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 The T bit MUST be set to 1, indicating that this is a control 560 message. 562 The L and S bits MUST be set to 1, indicating that the Length field 563 and sequence numbers are present. 565 The x bits are reserved for future extensions. All reserved bits 566 MUST be set to 0 on outgoing messages and ignored on incoming 567 messages. 569 The Ver field indicates the version of the L2TP control message 570 header described in this document. On sending, this field MUST be 571 set to 3 for all messages (unless operating in an environment which 572 includes L2TPv2 [RFC2661] and/or L2F [RFC2341] as well, see Section 573 4.1 for details). 575 The Length field indicates the total length of the message in octets, 576 always calculated from the start of the control message header itself 577 (beginning with the T bit). 579 The Control Connection ID field contains the identifier for the 580 control connection. L2TP control connections are named by 581 identifiers that have local significance only. That is, the same 582 control connection will be given unique Control Connection IDs by 583 each LCCE from within each endpoint's own Control Connection ID 584 number space. As such, the Control Connection ID in each message is 585 that of the intended recipient, not the sender. Non-zero Control 586 Connection IDs are selected and exchanged as Assigned Control 587 Connection ID AVPs during the creation of a control connection. 589 Ns indicates the sequence number for this control message, beginning 590 at zero and incrementing by one (modulo 2**16) for each message sent. 591 See Section 4.2 for more information on using this field. 593 Nr indicates the sequence number expected in the next control message 594 to be received. Thus, Nr is set to the Ns of the last in-order 595 message received plus one (modulo 2**16). See Section 4.2 for more 596 information on using this field. 598 3.2.2 L2TP Data Message 600 In general, an L2TP data message consists of a (1) Session Header, 601 (2) an optional L2-Specific Sublayer, and (3) the Tunnel Payload, as 602 depicted below. 604 Figure 3.2.2: L2TP Data Message Header 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | L2TP Session Header | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | L2-Specific Sublayer | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Tunnel Payload ... 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 The L2TP Session Header is specific to the encapsulating PSN over 615 which the L2TP traffic is delivered. The Session Header MUST provide 616 (1) a method of distinguishing traffic among multiple L2TP data 617 sessions and (2) a method of distinguishing data messages from 618 control messages. 620 Each type of encapsulating PSN MUST define its own session header, 621 clearly identifying the format of the header and parameters necessary 622 to setup the session. Section 4.1 defines two session headers, one 623 for transport over UDP and one for transport over IP. 625 The L2 Specific Sublayer is an intermediary layer between the L2TP 626 session header and the start of the tunneled frame. It contains 627 control fields that are used to facilitate the tunneling of each 628 frame (e.g. sequence numbers or flags). The default L2-Specific 629 Sublayer for L2TPv3 is defined in Section 4.6. 631 The Data Message Header is followed by the Tunnel Payload, including 632 any necessary L2 framing as defined in the payload-specific companion 633 documents. 635 3.3 Control Connection Management 637 The L2TP Control Connection handles dynamic establishment, teardown, 638 and maintenance of the L2TP sessions and of the control connection 639 itself. The reliable delivery of control messages is described in 640 Section 4.2. 642 This section describes typical control connection establishment and 643 teardown exchanges. It is important to note that, in the diagrams 644 that follow, the reliable control message delivery mechanism exists 645 independently of the L2TP state machine. For instance, Explicit 646 Acknowledgement (ACK) messages may be sent after any of the control 647 messages indicated in the exchanges below if an acknowledgment is not 648 piggybacked on a later control message. 650 LCCEs are identified during control connection establishment either 651 by the Host Name AVP, the Router ID AVP, or a combination of the two 652 (see Section 5.4.3). The identity of a peer LCCE is central to 653 selecting proper configuration parameters (i.e. Hello interval, 654 window size, etc.) for a control connection, as well as for 655 determination of how to setup associated sessions within the control 656 connection, password lookup for control connection authentication, 657 control connection level tie-breaking, etc. 659 3.3.1 Control Connection Establishment 661 Establishment of the control connection involves an exchange of AVPs 662 that identifies the peer and its capabilities. 664 A three-message exchange is used to establish the control connection. 665 The following is a typical message exchange: 667 LCCE A LCCE B 668 ------ ------ 669 SCCRQ -> 670 <- SCCRP 671 SCCCN -> 673 3.3.2 Control Connection Teardown 675 Control connection teardown may be initiated by either LCCE and is 676 accomplished by sending a single StopCCN control message. As part of 677 the reliable control message delivery mechanism, the recipient of a 678 StopCCN MUST send an ACK message to acknowledge receipt of the 679 message and maintain enough control connection state to properly 680 accept StopCCN retransmissions over at least a full retransmission 681 cycle (in case the ACK message is lost). The recommended time for a 682 full retransmission cycle is at least 31 seconds (see Section 4.2). 683 The following is an example of a typical control message exchange: 685 LCCE A LCCE B 686 ------ ------ 687 StopCCN -> 688 (Clean up) 690 (Wait) 691 (Clean up) 693 An implementation may shut down an entire control connection and all 694 sessions associated with the control connection by sending the 695 StopCCN. Thus, it is not necessary to clear each session 696 individually when tearing down the whole control connection. 698 3.4 Session Management 700 After successful control connection establishment, individual 701 sessions may be created. Each session corresponds to a single data 702 stream between the two LCCEs. This section describes the typical 703 call establishment and teardown exchanges. 705 3.4.1 Session Establishment for an Incoming Call 707 A three-message exchange is used to establish the session. The 708 following is a typical sequence of events: 710 LCCE A LCCE B 711 ------ ------ 712 (Call 713 Detected) 715 ICRQ -> 716 <- ICRP 717 (Call 718 Accepted) 720 ICCN -> 722 3.4.2 Session Establishment for an Outgoing Call 724 A three-message exchange is used to set up the session. The 725 following is a typical sequence of events: 727 LCCE A LCCE B 728 ------ ------ 729 <- OCRQ 730 OCRP -> 732 (Perform 733 Call 734 Operation) 736 OCCN -> 738 (Call Operation 739 Completed 740 Successfully) 742 3.4.3 Session Teardown 744 Session teardown may be initiated by either the LAC or LNS and is 745 accomplished by sending a CDN control message. After the last 746 session is cleared, the control connection MAY be torn down as well 747 (and typically is). The following is an example of a typical control 748 message exchange: 750 LCCE A LCCE B 751 ------ ------ 752 CDN -> 753 (Clean up) 755 (Clean up) 757 4. Protocol Operation 759 4.1 L2TP Over Specific Packet-Switched Networks (PSN) 761 If necessary, L2TP may operate over a variety of Packet Switched 762 Networks. There are two modes described for operation over IPv4, L2TP 763 over IP (Section 4.1.1) and L2TP over UDP (Section 4.1.2). L2TPv3 764 implementations MUST support L2TP over IP and SHOULD support L2TP 765 over UDP for better NAT and FW traversal, and easier migration from 766 L2TPv2. 768 L2TP over other PSNs may be defined, but the specifics are outside 769 the scope of this document. Examples of L2TPv2 over other PSNs 770 include [RFC3070] and [RFC3355]. 772 The following field definitions are defined for use in all L2TP 773 Session Header encapsulations. 775 Session ID 777 A 32-bit field containing a non-zero identifier for a session. 778 L2TP sessions are named by identifiers that have local 779 significance only. That is, the same logical session will be 780 given different Session IDs by each end of the control connection 781 for the life of the session. When the L2TP control connection is 782 used for session establishment, Session IDs are selected and 783 exchanged as Local Session ID AVPs during the creation of a 784 session. 786 Cookie 788 The optional Cookie field contains a variable length (maximum 64 789 bits), value used to check the association of a received data 790 message with the session identified by the Session ID. The Cookie 791 MUST be set to the configured or signaled random value for this 792 session utilizing all bits in the field. The Cookie provides an 793 additional level of guarantee that a data message has been 794 directed to the proper session by the Session ID. A well-chosen 795 Cookie may prevent inadvertent misdirection of stray packets with 796 recently reused Session IDs, Session IDs subject to packet 797 corruption, etc. The Cookie may also provide protection against 798 some specific malicious packet insertion attacks, as described in 799 section 8.2. 801 When the L2TP control connection is used for session 802 establishment, random Cookie values are selected and exchanged as 803 Assigned Cookie AVPs during session creation. 805 4.1.1 L2TPv3 over IP 807 L2TPv3 over IP utilizes the IANA assigned IP protocol ID 115. 809 4.1.1.1 L2TPv3 Session Header Over IP 811 Unlike L2TP over UDP, the L2TPv3 session header over IP is free of 812 any restrictions imposed by coexistence with L2TPv2 and L2F. As 813 such, the header format has been redesigned to optimize packet 814 processing. The following session header format is utilized when 815 operating L2TPv3 over IP: 817 Figure 4.1.1.1: L2TPv3 Session Header Over IP 819 0 1 2 3 820 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 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Session ID | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | Cookie (optional, maximum 64 bits)... 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 The Session ID and Cookie fields are as defined in Section 4.1. The 830 Session ID of zero is reserved for use by L2TP control messages (see 831 Section 4.1.1.2). 833 4.1.1.2 L2TP Control and Data Traffic over IP 835 Unlike L2TP over UDP which uses the common T bit to distinguish 836 between L2TP control and data packets, L2TP over IP uses the reserved 837 Session ID of zero (0) when sending control messages. It is presumed 838 that checking for the zero Session ID is more efficient -- both in 839 header size for data packets and in processing speed for 840 distinguishing between control and data messages -- than checking for 841 the presence of a given single bit. 843 The entire control message header over IP, including the zero session 844 ID, appears as follows: 846 Figure 4.1.1.2: L2TPv3 Control Message Header Over IP 848 0 1 2 3 849 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 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | (32 bits of zeros) | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 |T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Control Connection ID | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Ns | Nr | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Named fields are as defined in Section 3.2.1. Note that the Length 861 field is still calculated from the beginning of the control message 862 header, beginning with the T bit. It does NOT include the "(32 bits 863 of zeros)" depicted above. 865 When operating directly over IP, L2TP packets lose the ability to 866 take advantage of the UDP checksum as a simple packet integrity 867 check. This is of particular concern for L2TP control messages. 868 Control Message Authentication (Section 4.3), even with an empty 869 password field, provides for a sufficient packet integrity check and 870 SHOULD always be enabled. 872 4.1.2 L2TP over UDP 874 L2TPv3 over UDP must consider other L2 tunneling protocols that may 875 be operating in the same environment, including L2TPv2 [RFC2661] and 876 L2F [RFC2341]. 878 While there are efficiencies gained by running L2TP directly over IP, 879 there are possible side effects as well. For instance, L2TP over IP 880 is not as NAT-friendly as L2TP over UDP. 882 4.1.2.1 L2TP Session Header Over UDP 884 The following session header format is utilized when operating L2TPv3 885 over UDP: 887 Figure 4.1.2.1: L2TPv3 Session Header over UDP 889 0 1 2 3 890 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 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 |T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Session ID | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Cookie (optional, maximum 64 bits)... 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 The T bit MUST be set to 0, indicating that this is a data message. 903 The x bits and Reserved field are reserved for future extensions. 904 All reserved values MUST be set to 0 on outgoing messages and ignored 905 on incoming messages. 907 The Ver field MUST be set to 3, indicating an L2TPv3 message. 909 Note that the initial bits 1, 4, 6 and 7 have meaning in L2TPv2 910 [RFC2661], and are deprecated and marked as reserved in L2TPv3. Thus, 911 for UDP mode on a system that supports both versions of L2TP, it is 912 important that the Ver field be inspected first to determine the 913 Version of the header before acting upon any of these bits. 915 The Session ID and Cookie fields are as defined in Section 4.1. 917 4.1.2.2 UDP Port Selection 919 The method for UDP Port Selection defined in this section is 920 identical to than defined for L2TPv2 [RFC2661]. 922 When negotiating a control connection over UDP, control messages MUST 923 be sent as UDP datagrams using the registered UDP port 1701 924 [RFC1700]. The initiator of an L2TP control connection picks an 925 available source UDP port (which may or may not be 1701), and sends 926 to the desired destination address at port 1701. The recipient picks 927 a free port on its own system (which may or may not be 1701) and 928 sends its reply to the initiator's UDP port and address, setting its 929 own source port to the free port it found. 931 Any subsequent traffic associated with this control connection 932 (either control traffic or data traffic from a session established 933 through this control connection) must use these same UDP ports. 935 It has been suggested that having the recipient choose an arbitrary 936 source port (as opposed to using the destination port in the packet 937 initiating the control connection, i.e., 1701) may make it more 938 difficult for L2TP to traverse some NAT devices. Implementations 939 should consider the potential implication of this capability before 940 choosing an arbitrary source port. A NAT device that can pass TFTP 941 traffic with variant UDP ports should be able to pass L2TP UDP 942 traffic since both protocols employ similar policies with regard to 943 UDP port selection. 945 4.1.2.3 UDP Checksum 947 UDP checksums MUST be enabled for control messages and MAY be enabled 948 for data messages. It should be noted that enabling checksums on 949 data packets may significantly increase the data packet processing 950 burden. 952 4.1.3 IP Fragmentation Issues 954 IP fragmentation may occur as the L2TP packet travels over the IP 955 substrate. L2TP makes no special efforts defined in this document to 956 optimize this. 958 4.2 Reliable Delivery of Control Messages 960 L2TP provides a lower level reliable delivery service for all control 961 messages. The Nr and Ns fields of the control message header (see 962 Section 3.2.1) belong to this delivery mechanism. The upper level 963 functions of L2TP are not concerned with retransmission or ordering 964 of control messages. The reliable control messaging mechanism is a 965 sliding window mechanism that provides control message retransmission 966 and congestion control. Each peer maintains separate sequence number 967 state for each control connection. 969 The message sequence number, Ns, begins at 0. Each subsequent 970 message is sent with the next increment of the sequence number. The 971 sequence number is thus a free-running counter represented modulo 972 65536. The sequence number in the header of a received message is 973 considered less than or equal to the last received number if its 974 value lies in the range of the last received number and the preceding 975 32767 values, inclusive. For example, if the last received sequence 976 number was 15, then messages with sequence numbers 0 through 15, as 977 well as 32784 through 65535, would be considered less than or equal. 978 Such a message would be considered a duplicate of a message already 979 received and ignored from processing. However, in order to ensure 980 that all messages are acknowledged properly (particularly in the case 981 of a lost ACK message), receipt of duplicate messages MUST be 982 acknowledged by the reliable delivery mechanism. This acknowledgment 983 may either piggybacked on a message in queue or sent explicitly via 984 an ACK message. 986 All control messages take up one slot in the control message sequence 987 number space, except the ACK message. Thus, Ns is not incremented 988 after an ACK message is sent. 990 The last received message number, Nr, is used to acknowledge messages 991 received by an L2TP peer. It contains the sequence number of the 992 message the peer expects to receive next (e.g. the last Ns of a non- 993 ACK message received plus 1, modulo 65536). While the Nr in a 994 received ACK message is used to flush messages from the local 995 retransmit queue (see below), the Nr of the next message sent is not 996 updated by the Ns of the ACK message. Nr SHOULD be sanity-checked 997 before flushing the retransmit queue. For instance, if the Nr 998 received in a control message is greater than the last Ns sent plus 1 999 modulo 65536, the control message is clearly invalid. 1001 The reliable delivery mechanism at a receiving peer is responsible 1002 for making sure that control messages are delivered in order and 1003 without duplication to the upper level. Messages arriving out of 1004 order may be queued for in-order delivery when the missing messages 1005 are received. Alternatively, they may be discarded, thus requiring a 1006 retransmission by the peer. When dropping out of order control 1007 packets, Nr MAY be updated before the packet is discarded. 1009 Each control connection maintains a queue of control messages to be 1010 transmitted to its peer. The message at the front of the queue is 1011 sent with a given Ns value and is held until a control message 1012 arrives from the peer in which the Nr field indicates receipt of this 1013 message. After a period of time (a recommended default is 1 second 1014 but SHOULD be configurable) passes without acknowledgment, the 1015 message is retransmitted. The retransmitted message contains the 1016 same Ns value, but the Nr value MUST be updated with the sequence 1017 number of the next expected message. 1019 Each subsequent retransmission of a message MUST employ an 1020 exponential backoff interval. Thus, if the first retransmission 1021 occurred after 1 second, the next retransmission should occur after 2 1022 seconds has elapsed, then 4 seconds, etc. An implementation MAY 1023 place a cap upon the maximum interval between retransmissions. This 1024 cap SHOULD be no less than 8 seconds per retransmission. If no peer 1025 response is detected after several retransmissions (a recommended 1026 default is 10, but MUST be configurable), the control connection and 1027 all associated sessions MUST be cleared. As it is the first message 1028 to establish a control connection, the SCCRQ MAY employ a different 1029 retransmission maximum than other control messages in order to help 1030 facilitate failover to alternate LCCEs in a timely fashion. 1032 When a control connection is being shut down for reasons other than 1033 loss of connectivity, the state and reliable delivery mechanisms MUST 1034 be maintained and operated for the full retransmission interval after 1035 the final message StopCCN message has been sent (e.g. 1 + 2 + 4 + 8 + 1036 8... seconds), or until the StopCCN message itself has been 1037 acknowledged. 1039 A sliding window mechanism is used for control message transmission 1040 and retransmission. Consider two peers, A and B. Suppose A 1041 specifies a Receive Window Size AVP with a value of N in the SCCRQ or 1042 SCCRP message. B is now allowed to have a maximum of N outstanding 1043 (e.g. unacknowledged) control messages. Once N messages have been 1044 sent, B must wait for an acknowledgment from A that advances the 1045 window before sending new control messages. An implementation may 1046 advertise a non-zero receive window as small or as large as it 1047 wishes, depending on its own ability to process incoming messages 1048 before sending an acknowledgement. Each peer MUST limit the number of 1049 unacknowledged messages it will send before receiving an 1050 acknowledgement by this Receive Window Size. The actual internal 1051 unacknowledged message send-queue depth may be further limited by 1052 local resource allocation or by dynamic slow-start and congestion- 1053 avoidance mechanisms. 1055 When retransmitting control messages, a slow start and congestion 1056 avoidance window adjustment procedure SHOULD be utilized. A 1057 recommended procedure is described in Appendix A. A peer MAY drop 1058 messages, but MUST NOT actively delay acknowledgment of messages as a 1059 technique for flow control of control messages. Appendix B contains 1060 examples of control message transmission, acknowledgment, and 1061 retransmission. 1063 4.3 Control Connection and Control Message Authentication 1065 L2TP incorporates an optional authentication and integrity check for 1066 all control messages. This mechanism consists of a computed one-way 1067 hash over the header and body of the L2TP control message, a pre- 1068 configured shared secret, and a local and remote nonce (random value) 1069 exchanged via the Nonce AVP. This per-message authentication and 1070 integrity check is designed to perform a mutual authentication 1071 between L2TP nodes, integrity checking of all control messages, and 1072 guard against control message spoofing and replay attacks that would 1073 otherwise be trivial to mount. 1075 A shared secret (password) MUST exist between communicating L2TP 1076 nodes to enable the authentication mode. See Section 5.4.3 for 1077 details on calculation of the Message Digest and construction of the 1078 Nonce and Message Digest AVPs. 1080 L2TPv3 Control Connection and Control Message Authentication is 1081 similar to L2TPv2 [RFC2661] Tunnel Authentication in its use of a 1082 shared secret for peer authentication, use of a one-way hash 1083 calculation, and exchange of a random value. The principal difference 1084 is that, instead of computing the hash over selected contents of a 1085 received control message (e.g. the Challenge AVP and Message Type) as 1086 in L2TPv2, the entire message is used in the hash in L2TPv3. In 1087 addition, instead of including the hash digest in just the SCCRP and 1088 SCCCN messages, it is now included in all L2TP messages. 1090 The Control Message Authentication mechanism is optional, and may be 1091 disabled if both peers agree. For example, if IPsec is already being 1092 used for security and integrity checking between the LCCEs, the 1093 function of the L2TP mechanism becomes redundant and may be disabled. 1095 Presence of the Control Message Authentication Nonce AVP in an SCCRQ 1096 or SCCRP message serves as indication to a peer that Control Message 1097 Authentication is enabled. If an SCCRQ or SCCRP contains a Control 1098 Message Authentication Nonce AVP, the receiver of the message MUST 1099 respond with a Message Digest AVP in all subsequent messages sent. 1100 Control Connection and Control Message Authentication is always 1101 bidirectional, either both sides participate in authentication or 1102 neither do. 1104 If the Control Message Authentication is disabled, the Message Digest 1105 AVP still MAY be sent containing an integrity check of the message. 1106 The integrity check is calculated as in Section 5.4.3, with an empty 1107 and zero length shared secret, local nonce, and remote nonce. If a 1108 erroneous Message Digest AVP is received, it should be assumed that a 1109 bit error has occurred and the control message dropped. 1111 Implementations MAY rate-limit control messages, particularly SCCRQ 1112 messages, upon receipt for performance reasons or to protect against 1113 denial of service attacks. 1115 4.4 Keepalive (Hello) 1117 A keepalive mechanism is employed by L2TP to detect loss of 1118 connectivity between a pair of LCCEs. This is accomplished by 1119 injecting Hello control messages (see Section 6.5) after a period of 1120 time has elapsed since the last data message or control message was 1121 received on an L2TP session or control connection, respectively. As 1122 with any other control message, if the Hello message is not reliably 1123 delivered, the sending LCCE declares that the control connection is 1124 down and resets its state for the control connection. This behavior 1125 ensures that a connectivity failure between the LCCEs is detected 1126 independently by each end of a control connection. 1128 Since the control channel is operated in-band with data traffic over 1129 the PSN, this single mechanism can be used to infer basic data 1130 connectivity between a pair of LCCEs for all sessions associated with 1131 the control connection. 1133 Periodic keepalive for the control connection MUST be implemented by 1134 sending a Hello if a period of time (a recommended default is 60 1135 seconds, but MUST be configurable) has passed without receiving any 1136 message (data or control) from the peer. An LCCE sending Hello 1137 messages across multiple control connections between the same LCCE 1138 endpoints MUST employ a jittered timer mechanism to prevent grouping 1139 of Hello messages. 1141 4.5 Forwarding Session Data Frames 1143 Once session establishment is complete, circuit frames are received 1144 at an LCCE, encapsulated in L2TP (with appropriate attention to 1145 framing as described in documents for the particular pseudowire 1146 type), and forwarded over the appropriate session. For every 1147 outgoing data message, the sender places the identifier specified in 1148 the Local Session ID AVP (received from peer during session 1149 establishment) in the Session ID field of the L2TP data header. In 1150 this manner, session frames are multiplexed and demultiplexed between 1151 a given pair of LCCEs. Multiple control connections may exist 1152 between a given pair of LCCEs, and multiple sessions may be 1153 associated with a given control connection. 1155 The peer LCCE receiving the L2TP data packet identifies the session 1156 with which the packet is associated by the Session ID in the data 1157 packet's header. The LCCE then checks the Cookie field in the data 1158 packet against the Cookie value received in the Assigned Cookie AVP 1159 during session establishment. It is important for implementers to 1160 note that the Cookie field check occurs after looking up the session 1161 context by the Session ID, and as such consists merely of a value 1162 match of the Cookie field and that stored in the retrieved context. 1163 There is no need to perform a lookup across the Session ID and Cookie 1164 as a single value. Any received data packets that contain invalid 1165 Session IDs or associated Cookie values MUST be dropped. Finally, 1166 the LCCE either forwards the network packet within the tunneled frame 1167 (e.g., as an LNS) or switches the frame to a circuit (e.g., as an 1168 LAC). 1170 4.6 Default L2-Specific Sublayer 1172 This document defines a default L2-Specific Sublayer (see Section 1173 3.2.2) format that a pseudowire may use for features such as 1174 sequencing support, L2 interworking, OAM, or other per-data-packet 1175 operations. The default L2-Specific Sublayer SHOULD be used by a 1176 given PW type to support these features if it is adequate, and its 1177 presence is requested by a peer during session negotiation. 1178 Alternative sublayers MAY be defined (e.g. an encapsulation with a 1179 larger Sequence Number field or timing information) and identified 1180 for use via the L2-Specific Sublayer Type AVP. 1182 Figure 4.6: Default L2-Specific Sublayer Format 1184 0 1 2 3 1185 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 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 |x|S|x|x|x|x|x|x| Sequence Number | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 The S (Sequence) bit is set to 1 when the Sequence Number contains a 1191 valid number for this sequenced frame. If the S bit is set to zero, 1192 the Sequence Number contents are undefined and MUST be ignored by the 1193 receiver. 1195 The Sequence Number field contains a free-running counter of 2^24 1196 sequence numbers. If the number in this field is valid, the S bit 1197 MUST be set to 1. The Sequence Number begins at zero, which is a 1198 valid sequence number. (In this way, implementations inserting 1199 sequence numbers do not have to "skip" zero when incrementing.) The 1200 sequence number in the header of a received message is considered 1201 less than or equal to the last received number if its value lies in 1202 the range of the last received number and the preceding (2^23-1) 1203 values, inclusive. 1205 4.6.1 Sequencing Data Packets 1207 The Sequence Number field may be used to detect lost, duplicate, or 1208 out-of-order packets within a given session. 1210 When L2 frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP 1211 data channel, this part of the link has the characteristic of being 1212 able to reorder, duplicate, or silently drop packets. Reordering may 1213 break some non-IP protocols or L2 control traffic being carried by 1214 the link. Silent dropping or duplication of packets may break 1215 protocols that assume per-packet indications of error, such as TCP 1216 header compression. While a common mechanism for packet sequence 1217 detection is provided, the sequence dependency characteristics of 1218 individual protocols are outside the scope of this document. 1220 If any protocol being transported by over L2TP data channels cannot 1221 tolerate misordering of data packets, packet duplication, or silent 1222 packet loss, sequencing may be enabled on some or all packets by 1223 using the S bit and Sequence Number field defined in the default L2- 1224 Specific Sublayer(see Section 4.6). For a given L2TP session, each 1225 LCCE is responsible for communicating to its peer the level of 1226 sequencing support that it requires of data packets that it receives. 1227 Mechanisms to advertise this information during session negotiation 1228 are provided (see Data Sequencing AVP in Section 5.4.4). 1230 When determining whether a packet is in or out of sequence, an 1231 implementation SHOULD utilize a method that is resilient to temporary 1232 dropouts in connectivity coupled with high per-session packet rates. 1233 The recommended method is outlined in Appendix C. 1235 4.7 L2TPv2/v3 Interoperability and Migration 1237 L2TPv2 and L2TPv3 environments should be able to coexist while a 1238 migration to L2TPv3 is made. Migration issues are discussed for each 1239 media type in this section. Most issues apply only to 1240 implementations that require both L2TPv2 and L2TPv3 operation. 1241 However, even L2TPv3-only implementations must at least be mindful of 1242 these issues in order to interoperate with implementations that 1243 support both versions. 1245 4.7.1 L2TPv3 over IP 1247 L2TPv3 implementations running strictly over IP with no desire to 1248 interoperate with L2TPv2 implementations may safely disregard most 1249 migration issues from L2TPv2. All control messages and data messages 1250 are sent as described in this document, without normative reference 1251 to RFC2661. 1253 If one wishes to tunnel PPP over L2TPv3, and fallback to L2TPv2 only 1254 if it is not available, then L2TPv3 over UDP with the automatic 1255 fallback as described in section 4.7.3 MUST be used. There is no 1256 deterministic method for automatic fallback from L2TPv3 over IP to 1257 either L2TPv2 or L2TPv3 over UDP. One could infer whether L2TPv3 over 1258 IP is supported by sending an SCCRQ and waiting for a response, but 1259 this could be problematic during periods of packet loss between L2TP 1260 nodes. 1262 4.7.2 L2TPv3 over UDP 1264 The format of the L2TPv3 over UDP header is defined in Section 1265 4.1.2.1. 1267 When operating over UDP, L2TPv3 uses the same port (1701) as L2TPv2 1268 and shares the first two octets of header format with L2TPv2. The Ver 1269 field is used to distinguish L2TPv2 packets from L2TPv3 packets. If 1270 an implementation is capable of operating in L2TPv2 or L2TPv3 modes, 1271 it is possible to automatically detect whether a peer can support 1272 L2TPv2 or L2TPv3 and operate accordingly. The details of this 1273 fallback capability is defined in the following section. 1275 4.7.3 Automatic L2TPv2 Fallback 1277 When running over UDP, an implementation may detect whether a peer is 1278 L2TPv3-capable by sending a special SCCRQ that is properly formatted 1279 for both L2TPv2 and L2TPv3. This is accomplished by sending an SCCRQ 1280 with its Ver field set to 2 (for L2TPv2), and ensuring that any 1281 L2TPv3-specific AVPs (i.e. AVPs present within this document and not 1282 defined within RFC 2661) within the message are sent with each M bit 1283 set to 0, and all L2TPv2 AVPs present as they would be for L2TPv2. 1284 This is done so that L2TPv3 AVPs will be ignored by an L2TPv2-only 1285 implementation. Note that, in both L2TPv2 and L2TPv3, the value 1286 contained in the space of the control message header utilized by the 1287 32-bit Control Connection ID in L2TPv3, and the 16-bit Tunnel ID and 1288 16-bit Session ID in L2TPv2, is always 0 for an SCCRQ. This 1289 effectively hides the fact that there are a pair of 16-bit fields in 1290 L2TPv2, and a single 32-bit field in L2TPv3. 1292 If the peer implementation is L2TPv3-capable, a control message with 1293 Ver set to 3 and corresponding header and message format will be sent 1294 in response to the SCCRQ. Operation may then continue as L2TPv3. If 1295 a message is received with Ver set to 2, it must be assumed that the 1296 peer implementation is L2TPv2-only and fallback to L2TPv2 mode may 1297 safely occur. 1299 Note Well: The L2TPv2/v3 auto-detection mode requires that all L2TPv3 1300 implementations over UDP be liberal in acceptance of an SCCRQ control 1301 message with the Ver field set to 2 or 3 and the presence of L2TPv2- 1302 specific AVPs. An L2TPv3-only implementation MUST ignore all L2TPv2 1303 AVPs (e.g. those defined in RFC 2661 and not in this document) within 1304 an SCCRQ with the Ver field set to 2 (even if the M bit is set on the 1305 L2TPv2-specific AVPs). 1307 5. Control Message Attribute Value Pairs 1309 To maximize extensibility while permitting interoperability, a 1310 uniform method for encoding message types is used throughout L2TP. 1311 This encoding will be termed AVP (Attribute Value Pair) for the 1312 remainder of this document. 1314 5.1 AVP Format 1316 Each AVP is encoded as follows: 1318 Figure 5.1: AVP Format 1320 0 1 2 3 1321 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 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 |M|H| rsvd | Length | Vendor ID | 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | Attribute Type | Attribute Value ... 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 (until Length is reached) | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 The first six bits comprise a bit mask that describes the general 1331 attributes of the AVP. Two bits are defined in this document; the 1332 remaining bits are reserved for future extensions. Reserved bits 1333 MUST be set to 0. An AVP received with a reserved bit set to 1 MUST 1334 be treated as an unrecognized AVP. 1336 Mandatory (M) bit: Controls the behavior required of an 1337 implementation that receives an unrecognized AVP. The M bit of a 1338 given AVP MUST only be inspected and acted upon if the AVP is 1339 unrecognized (see Section 5.2). 1341 Hidden (H) bit: Identifies the hiding of data in the Attribute Value 1342 field of an AVP. This capability can be used to avoid the passing of 1343 sensitive data, such as user passwords, as cleartext in an AVP. 1344 Section 5.3 describes the procedure for performing AVP hiding. 1346 Length: Contains the number of octets (including the Overall Length 1347 and bit mask fields) contained in this AVP. The Length may be 1348 calculated as 6 + the length of the Attribute Value field in octets. 1349 The field itself is 10 bits, permitting a maximum of 1023 octets of 1350 data in a single AVP. The minimum Length of an AVP is 6. If the 1351 Length is 6, then the Attribute Value field is absent. 1353 Vendor ID: The IANA assigned "SMI Network Management Private 1354 Enterprise Codes" [RFC1700] value. The value 0, corresponding to 1355 IETF adopted attribute values, is used for all AVPs defined within 1356 this document. Any vendor wishing to implement its own L2TP 1357 extensions can use its own Vendor ID along with private Attribute 1358 values, guaranteeing that they will not collide with any other 1359 vendor's extensions or future IETF extensions. Note that there are 1360 16 bits allocated for the Vendor ID, thus limiting this feature to 1361 the first 65,535 enterprises. 1363 Attribute Type: A 2-octet value with a unique interpretation across 1364 all AVPs defined under a given Vendor ID. 1366 Attribute Value: This is the actual value as indicated by the Vendor 1367 ID and Attribute Type. It follows immediately after the Attribute 1368 Type field and runs for the remaining octets indicated in the Length 1369 (i.e., Length minus 6 octets of header). This field is absent if the 1370 Length is 6. 1372 5.2 Mandatory AVPs and Setting the M Bit 1374 If the M bit is set on an AVP that is unrecognized by its recipient, 1375 the session or control connection associated with the contorl message 1376 containing the AVP MUST be shutdown. If the control message 1377 containing the unrecognized AVP is associated with a session (e.g. an 1378 ICRQ, ICRP, ICCN, SLI, etc.) then the session MUST be issued a CDN 1379 with a Result Code of 2 and Error Code of 8 as defined in section 1380 5.4.2. and shutdown. If the control message containing the 1381 unrecognized AVP is associated with establishment or maintenance of a 1382 Control Connection (e.g. SCCRQ, SCCRP, SCCCN, Hello) then the 1383 associated Control Connection MUST be issued a StopCCN with Result 1384 Code of 2 and Error Code of 8 as defined in section 5.4.2. and 1385 shutdown. If the M bit is not set on an unrecognized AVP, the AVP 1386 MUST be ignored when received, processing the control message as if 1387 the AVP was not present. 1389 Receipt of an unrecognized AVP that has the M bit set is catastrophic 1390 to the session or control connection with which it is associated. 1391 Thus, the M bit should only be set for AVPs that are deemed crucial 1392 to proper operation of the session or control connection by the 1393 sender. AVPs that are considered crucial by the sender may vary by 1394 application and configured options. In no case shall a receiver of 1395 an AVP "validate" if the M bit is set on a recognized AVP. If the AVP 1396 is recognized (as all AVPs defined in this document MUST be for a 1397 compliant L2TPv3 specification), then by definition the M bit is of 1398 no consequence. 1400 The sender of an AVP is free to set its M bit to 1 or 0 based on 1401 whether the configured application strictly requires the value 1402 contained in the AVP to be recognized or not. For example, "Automatic 1403 L2TPv2 Fallback" (Section 4.7.3), requires the setting of the M bit 1404 on all new L2TPv3 AVPs to zero if fallback to L2TPv2 is supported and 1405 desired, and 1 if not. 1407 The M bit is useful as extra assurance for support of critical AVP 1408 extensions. However, more explicit methods may be available to 1409 determine support for a given feature rather than using the M bit 1410 alone. For example, if a new AVP is defined in a message for which 1411 there is always a message reply (i.e. an ICRQ, ICRP, SCCRQ or SCCRP 1412 message) rather than simply sending an AVP in the message with the M 1413 bit set, availability of the extension may be identified by sending 1414 an AVP in the request message and expecting a corresponding AVP in a 1415 reply message. This more explicit method, when possible, is 1416 preferred. 1418 The M bit also plays a role in determining whether or not a malformed 1419 or out-of-range value within an AVP should be ignored or result in 1420 termination of a session or control channel. See Section 7.1 for more 1421 details on this. 1423 5.3 Hiding of AVP Attribute Values 1425 The H bit in the header of each AVP provides a mechanism to indicate 1426 to the receiving peer whether the contents of the AVP are hidden or 1427 present in cleartext. This feature can be used to hide sensitive 1428 control message data such as user passwords, IDs, or other vital 1429 information. 1431 The H bit MUST only be set if (1) a shared secret exists between the 1432 LCCEs and (2) Control Connection and Control Message Authentication 1433 is enabled (see Section 4.3). If the H bit is set in any AVP(s) in a 1434 given control message, a Random Vector AVP must also be present in 1435 the message and MUST precede the first AVP having an H bit of 1. 1437 The shared secret between LCCEs is used to derive a unique shared key 1438 for hiding and unhiding calculations. The derived shared key is 1439 obtained via a one-way HMAC-MD5 hash [RFC1321] on the shared secret 1440 concatenated with a single octet containing the value 1. 1442 shared_key = HMAC_MD5 (shared_secret | 1) 1444 Hiding an AVP value is done in several steps. The first step is to 1445 take the length and value fields of the original (cleartext) AVP and 1446 encode them into a Hidden AVP Subformat as follows: 1448 Figure 5.3: Hidden AVP Subformat 1450 0 1 2 3 1451 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | Length of Original Value | Original Attribute Value ... 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 ... | Padding ... 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 Length of Original Attribute Value: This is length of the Original 1460 Attribute Value to be obscured in octets. This is necessary to 1461 determine the original length of the Attribute Value that is lost 1462 when the additional Padding is added. 1464 Original Attribute Value: Attribute Value that is to be obscured. 1466 Padding: Random additional octets used to obscure length of the 1467 Attribute Value that is being hidden. 1469 To mask the size of the data being hidden, the resulting subformat 1470 MAY be padded as shown above. Padding does NOT alter the value 1471 placed in the Length of Original Attribute Value field, but does 1472 alter the length of the resultant AVP that is being created. For 1473 example, if an Attribute Value to be hidden is 4 octets in length, 1474 the unhidden AVP length would be 10 octets (6 + Attribute Value 1475 length). After hiding, the length of the AVP will become 6 + 1476 Attribute Value length + size of the Length of Original Attribute 1477 Value field + Padding. Thus, if Padding is 12 octets, the AVP length 1478 will be 6 + 4 + 2 + 12 = 24 octets. 1480 Next, an MD5 hash is performed (in network byte order) on the 1481 concatenation of the following: 1483 + the 2-octet Attribute number of the AVP 1484 + the shared key 1485 + an arbitrary length random vector 1487 The value of the random vector used in this hash is passed in the 1488 value field of a Random Vector AVP. This Random Vector AVP must be 1489 placed in the message by the sender before any hidden AVPs. The same 1490 random vector may be used for more than one hidden AVP in the same 1491 message. If a different random vector is used for the hiding of 1492 subsequent AVPs, then a new Random Vector AVP must be placed in the 1493 command message before the first AVP to which it applies. 1495 The MD5 hash value is then XORed with the first 16-octet (or less) 1496 segment of the Hidden AVP Subformat and placed in the Attribute Value 1497 field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 1498 octets, the Subformat is transformed as if the Attribute Value field 1499 had been padded to 16 octets before the XOR. Only the actual octets 1500 present in the Subformat are modified, and the length of the AVP is 1501 not altered. 1503 If the Subformat is longer than 16 octets, a second one-way MD5 hash 1504 is calculated over a stream of octets consisting of the shared key 1505 followed by the result of the first XOR. That hash is XORed with the 1506 second 16-octet (or less) segment of the Subformat and placed in the 1507 corresponding octets of the Value field of the Hidden AVP. 1509 If necessary, this operation is repeated, with the shared key used 1510 along with each XOR result to generate the next hash to XOR the next 1511 segment of the value with. 1513 The hiding method was adapted from [RFC2865], which was taken from 1514 the "Mixing in the Plaintext" section in the book "Network Security" 1515 by Kaufman, Perlman and Speciner [KPS]. A detailed explanation of 1516 the method follows: 1518 Call the shared key S, the Random Vector RV, and the Attribute Value 1519 AV. Break the value field into 16-octet chunks p1, p2, etc., with 1520 the last one padded at the end with random data to a 16-octet 1521 boundary. Call the ciphertext blocks c(1), c(2), etc. We will also 1522 define intermediate values b1, b2, etc. 1524 b1 = MD5(AV + S + RV) c(1) = p1 xor b1 1525 b2 = MD5(S + c(1)) c(2) = p2 xor b2 1526 . . 1527 . . 1528 . . 1529 bi = MD5(S + c(i-1)) c(i) = pi xor bi 1531 The String will contain c(1)+c(2)+...+c(i), where + denotes 1532 concatenation. 1534 On receipt, the random vector is taken from the last Random Vector 1535 AVP encountered in the message prior to the AVP to be unhidden. The 1536 above process is then reversed to yield the original value. 1538 5.4 AVP Summary 1540 The following sections contain a list of all L2TP AVPs defined in 1541 this document. 1543 Following the name of the AVP is a list indicating the message types 1544 that utilize each AVP. After each AVP title follows a short 1545 description of the purpose of the AVP, a detail (including a graphic) 1546 of the format for the Attribute Value, and any additional information 1547 needed for proper use of the AVP. 1549 5.4.1 General Control Message AVPs 1551 Message Type (All Messages) 1553 The Message Type AVP, Attribute Type 0, identifies the control 1554 message herein and defines the context in which the exact meaning of 1555 the following AVPs will be determined. 1557 The Attribute Value field for this AVP has the following format: 1559 0 1 1560 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | Message Type | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 The Message Type is a 2-octet unsigned integer. 1567 The Message Type AVP MUST be the first AVP in a message, immediately 1568 following the control message header (defined in Section 3.2.1). See 1569 Section 3.1 for the list of defined control message types and their 1570 identifiers. 1572 The Mandatory (M) bit within the Message Type AVP has special 1573 meaning. Rather than an indication as to whether the AVP itself 1574 should be ignored if not recognized, it is an indication as to 1575 whether the control message itself should be ignored. If the M bit 1576 is set within the Message Type AVP and the Message Type is unknown to 1577 the implementation, the control connection MUST be cleared. If the M 1578 bit is not set, then the implementation may ignore an unknown message 1579 type. The M bit MUST be set to 1 for all message types defined in 1580 this document. This AVP MAY NOT be hidden (the H bit MUST be 0). 1581 The Length of this AVP is 8. 1583 A vendor-specific control message may be defined by setting the 1584 Vendor ID of the Message Type AVP to a value other than the IETF 1585 Vendor ID of 0 (see Section 5.1). The Message Type AVP MUST still be 1586 the first AVP in the control message. 1588 Message Digest (All Messages) 1590 The Message Digest AVP, Attribute Type AVP-TBA-1, is used as an 1591 integrity check and authentication of the L2TP Control Message 1592 header and body. 1594 The Attribute Value field for this AVP has the following format: 1596 0 1 2 3 1597 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 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | Digest Type | Message Digest ... 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 ... (16 or 20 octets) | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 Where Digest Type is a one octet integer indicating the Digest 1608 calculation algorithm: 1609 0 HMAC-MD5 [RFC1321] 1610 1 HMAC-SHA-1 [RFC2104] 1612 Digest type 0 (HMAC-MD5) MUST be supported, Digest Type 1 (HMAC- 1613 SHA-1) MAY be supported. 1615 The Message Digest is of variable length and contains the result 1616 of the control message authenticity and integrity calculation. For 1617 Digest Type 0 (HMAC-MD5) the length of the digest MUST be 16 1618 bytes. For Digest Type 1 (SHA-1) the digest MUST be 20 bytes. 1620 If Control Connection and Control Message Authentication is 1621 enabled, the Message Digest AVP MUST present in all messages and 1622 MUST be placed immediately after the Message Type AVP. This forces 1623 the Message Digest to be present within each message at a well- 1624 known and fixed offset. 1626 The shared secret between LCCEs is used to derive a unique shared 1627 key for Control Connection and Control Message Authentication 1628 calculations. The derived shared key is obtained via a one-way 1629 HMAC-MD5 hash [RFC1321] on the shared secret concatenated with a 1630 single octet containing the value 2. 1632 shared_key = HMAC_MD5 (shared_secret | 2) 1634 Calculation of the digest is as follows for all messages other 1635 than the SCCRQ: 1637 Digest = Hash (local_nonce | remote_nonce | shared_key | 1638 control_message) 1640 Hash: Hashing algorithm identified by the Digest Type 1642 local_nonce: Nonce chosen locally and advertised to the remote 1643 LCCE. 1645 remote_nonce: Nonce received from the remote LCCE 1647 (The local_nonce and remote_nonce are advertised via the 1648 Control Message Authentication Nonce AVP, also defined in this 1649 section.) 1651 shared_key: Derived shared key for this Control Connection 1653 control_message: The entire contents of the L2TP Control 1654 Message, including the Control Message header and all AVPs. 1656 Note that the Control Message header in this case begins after 1657 the 0 Session ID (see Section 4.1.1.2) when running over IP, 1658 and after the UDP header when running over UDP (see Section 1659 4.1.2.1). 1661 When calculating the Message Digest, the Message Digest AVP MUST 1662 be present within the control message with the Digest Type set to 1663 its proper value, but the Message Digest itself set to zeros. 1665 When receiving a control message, the contents of the Message 1666 Digest AVP MUST be compared against the expected digest value 1667 based on local calculation. This is done by performing the same 1668 digest calculation above, with the local_nonce and remote_nonce 1669 reversed. This message authenticity and integrity checking MUST be 1670 performed before utilizing any information contained within the 1671 control message. If the calculation fails, the message MUST be 1672 dropped. 1674 The SCCRQ has special treatment as it is the initial message 1675 commencing a new Control Connection. As such, there is only one 1676 nonce available. Since the nonce is present within the message 1677 itself as part of the Control Message Authentication Nonce AVP, 1678 there is no need to use it in the calculation explicitly. 1679 Calculation of the SCCRQ Digest is performed as follows: 1681 Digest = Hash (shared_key | control_message) 1683 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1684 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1685 Length is 23 for Digest Type 1 (HMAC-MD5), and 27 for Digest Type 1686 2 (SHA-1). Control Message Authentication Nonce (SCCRQ, SCCRP) 1688 The Control Message Authentication Nonce AVP, Attribute Type 1689 AVP-TBA-15, MUST contain a cryptographically random value 1690 [RFC1750]. This value is used for Control Message 1691 Authentication. 1693 The Attribute Value field for this AVP has the following 1694 format: 1696 0 1 2 3 1697 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 1698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1699 | Nonce ... (arbitrary number of octets) 1700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 The Nonce is of arbitrary length, though at least 16 octets is 1703 recommended. The Nonce contains the random value for use in 1704 the Control Message Authentication hash calculation (see 1705 Message Digest AVP definition in this section). 1707 If Control Connection and Message Authentication is enabled, 1708 this AVP MUST be present in the SCCRQ and SCCRP messages. 1710 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit 1711 for this AVP SHOULD be set to 1, but MAY vary (see Section 1712 5.2). The Length of this AVP is 6 plus the length of the Nonce. 1714 Random Vector (All Messages) 1716 The Random Vector AVP, Attribute Type 36, MUST contain a 1717 cryptographically random value [RFC1750]. This value is used for AVP 1718 Hiding. 1720 The Attribute Value field for this AVP has the following format: 1722 0 1 2 3 1723 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 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 | Random Octet String ... (arbitrary number of octets) 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 The Random Octet String is of arbitrary length, though at least 16 1729 octets is recommended. The string contains the random vector for use 1730 in computing the MD5 hash to retrieve or hide the Attribute Value of 1731 a hidden AVP (see Section 5.3). 1733 More than one Random Vector AVP may appear in a message, in which 1734 case a hidden AVP uses the Random Vector AVP most closely preceding 1735 it. As such, at least one Random Vector AVP MUST precede the first 1736 AVP with the H bit set. 1738 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1739 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1740 Length of this AVP is 6 plus the length of the Random Octet String. 1742 5.4.2 Result and Error Codes 1744 Result Code (StopCCN, CDN) 1746 The Result Code AVP, Attribute Type 1, indicates the reason for 1747 terminating the control channel or session. 1749 The Attribute Value field for this AVP has the following format: 1751 0 1 2 3 1752 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 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 | Result Code | Error Code (optional) | 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 | Error Message ... (optional, arbitrary number of octets) | 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 The Result Code is a 2-octet unsigned integer. The optional Error 1760 Code is a 2-octet unsigned integer. An optional Error Message can 1761 follow the Error Code field. Presence of the Error Code and Message 1762 is indicated by the AVP Length field. The Error Message contains an 1763 arbitrary string providing further (human-readable) text associated 1764 with the condition. Human-readable text in all error messages MUST 1765 be provided in the UTF-8 charset using the Default Language 1766 [RFC2277]. 1768 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1769 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1770 Length is 8 if there is no Error Code or Message, 10 if there is an 1771 Error Code and no Error Message, or 10 plus the length of the Error 1772 Message if there is an Error Code and Message. 1774 Defined Result Code values for the StopCCN message are as follows: 1776 0 - Reserved. 1777 1 - General request to clear control connection. 1778 2 - General error, Error Code indicates the problem. 1779 3 - Control channel already exists. 1780 4 - Requester is not authorized to establish a control channel. 1781 5 - The protocol version of the requester is not supported, 1782 Error Code indicates highest version supported. 1783 6 - Requester is being shut down. 1784 7 - Finite state machine error or timeout 1786 General Result Code values for the CDN message are as follows: 1788 0 - Reserved. 1789 1 - Session disconnected due to loss of carrier or circuit disconnect. 1790 2 - Session disconnected for the reason indicated in Error Code. 1791 3 - Session disconnected for administrative reasons. 1792 4 - Session establishment failed due to lack of appropriate 1793 facilities being available (temporary condition). 1794 5 - Session establishment failed due to lack of appropriate 1795 facilities being available (permanent condition). 1796 6 - 11 Reserved (PPP-specific codes defined outside this document). 1797 RC-TBA-1 - Session not established due to losing tie breaker. 1798 RC-TBA-2 - Session not established due to unsupported PW type. 1800 RC-TBA-3 - Session not established, sequencing required without valid 1801 L2-Specific Sublayer. 1802 RC-TBA-4 - Finite state machine error or timeout. 1804 Additional service-specific Result Codes are defined outside this 1805 document. 1807 The Error Codes defined below pertain to types of errors that are not 1808 specific to any particular L2TP request, but rather to protocol or 1809 message format errors. If an L2TP reply indicates in its Result Code 1810 that a general error occurred, the General Error value should be 1811 examined to determine what the error was. The currently defined 1812 General Error codes and their meanings are as follows: 1814 0 - No general error. 1815 1 - No control connection exists yet for this pair of LCCEs. 1816 2 - Length is wrong. 1817 3 - One of the field values was out of range. 1818 4 - Insufficient resources to handle this operation now. 1819 5 - Invalid Session ID. 1820 6 - A generic vendor-specific error occurred. 1821 7 - Try another. If initiator is aware of other possible responder 1822 destinations, it should try one of them. This can be 1823 used to guide an LAC or LNS based on policy. 1824 8 - The session or control connection was shut down due to receipt of 1825 an unknown AVP with the M bit set (see Section 5.2). The Error 1826 Message SHOULD contain the attribute of the offending AVP in 1827 (human-readable) text form. 1828 9 - Try another directed. If an LAC or LNS is aware of other possible 1829 destinations, it should inform the initiator of the control 1830 connection or session. The Error Message MUST contain a 1831 comma-separated list of addresses from which the initiator may 1832 choose. If the L2TP data channel runs over IPv4, then this would 1833 be a comma-separated list of IP addresses in the canonical 1834 dotted-decimal format (e.g. "10.0.0.1, 10.0.0.2, 10.0.0.3") in the 1835 UTF-8 charset using the Default Language [RFC2277]. If there are 1836 no servers for the LAC or LNS to suggest, then Error Code 7 should 1837 be used. The delimiter between addresses MUST be precisely a 1838 single comma and a single space. 1840 When a General Error Code of 6 is used, additional information about 1841 the error SHOULD be included in the Error Message field. A vendor- 1842 specific AVP MAY be sent to more precisely detail a vendor-specific 1843 problem. 1845 5.4.3 Control Connection Management AVPs 1847 Control Connection Tie Breaker (SCCRQ) 1849 The Control Connection Tie Breaker AVP, Attribute Type 5, indicates 1850 that the sender desires a single control connection to exist between 1851 a given pair of LCCEs. 1853 The Attribute Value field for this AVP has the following format: 1855 0 1 2 3 1856 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 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | Control Connection Tie Breaker Value ... 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 ... (64 bits) | 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 The Control Connection Tie Breaker Value is an 8-octet random value 1864 that is used to choose a single control connection when two LCCEs 1865 request a control connection concurrently. The recipient of a SCCRQ 1866 must check to see if a SCCRQ has been sent to the peer; if so, a tie 1867 has been detected. In this case, the LCCE must compare its Control 1868 Connection Tie Breaker value with the one received in the SCCRQ. The 1869 lower value "wins", and the "loser" MUST discard its control 1870 connection, sending a StopCCN if the SCCRQ that it had sent was 1871 acknowledged by the receiving peer. In the case in which a tie 1872 breaker is present on both sides and the value is equal, both sides 1873 MUST discard their control connections and restart control connection 1874 negotiation with a new, random tie breaker value. 1876 If a tie breaker is received and an outstanding SCCRQ has no tie 1877 breaker value, the initiator that included the Control Connection Tie 1878 Breaker AVP "wins". If neither side issues a tie breaker, then two 1879 separate control connections are opened. 1881 Applications which employ a distinct and well-known initiator have no 1882 need for tie-breaking, and this AVP MAY be omitted and the tie- 1883 breaking functionality disabled. Applications which require tie- 1884 breaking also require that an LCCE be uniquely identifiable upon 1885 receipt of an SCCRQ. For L2TP over IP, this MUST be accomplished via 1886 the Router ID AVP. 1888 Note that in [RFC2661], this AVP was referred to as the "Tie-Breaker 1889 AVP". Here, the AVP serves the same purpose and has the same 1890 attribute value and composition. The name was changed simply to 1891 distinguish between the Session and Control Connection Tie Breaker 1892 AVP. 1894 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1895 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1896 Length of this AVP is 14. 1898 Host Name (SCCRQ, SCCRP) 1900 The Host Name AVP, Attribute Type 7, indicates the name of the 1901 issuing LAC or LNS, encoded in the US-ASCII charset. 1903 The Attribute Value field for this AVP has the following format: 1905 0 1 2 3 1906 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 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 | Host Name ... (arbitrary number of octets) 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1911 The Host Name is of arbitrary length, but MUST be at least 1 octet. 1913 This name should be as broadly unique as possible; for hosts 1914 participating in DNS [RFC1034], a host name with fully qualified 1915 domain would be appropriate. The Host Name AVP and/or Router ID AVP 1916 MUST be used to identify an LCCE as described in Section 3.3. 1918 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1919 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1920 Length of this AVP is 6 plus the length of the Host Name. 1922 Router ID (SCCRQ, SCCRP) 1924 The Router ID AVP, Attribute Type AVP-TBA-2, is an identifier used to 1925 identify an LCCE for control connection setup, tie breaking, and/or 1926 tunnel authentication. 1928 The Attribute Value field for this AVP has the following format: 1930 0 1 2 3 1931 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 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 | Router Identifier | 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1936 The Router Identifier is a 4-octet unsigned integer. Its value is 1937 unique for a given LCCE, per Section 8.1 of [RFC2072]. The Host Name 1938 AVP and/or Router ID AVP MUST be used to identify an LCCE as 1939 described in Section 3.3. 1941 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1942 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1943 Length of this AVP is 10. 1945 Vendor Name (SCCRQ, SCCRP) 1947 The Vendor Name AVP, Attribute Type 8, contains a vendor-specific 1948 (possibly human-readable) string describing the type of LAC or LNS 1949 being used. 1951 The Attribute Value field for this AVP has the following format: 1953 0 1 2 3 1954 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 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 | Vendor Name ... (arbitrary number of octets) 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 The Vendor Name is the indicated number of octets representing the 1960 vendor string. Human-readable text for this AVP MUST be provided in 1961 the US-ASCII charset [RFC1958, RFC2277]. 1963 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 1964 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 1965 (before hiding) of this AVP is 6 plus the length of the Vendor Name. 1967 Assigned Control Connection ID (SCCRQ, SCCRP, StopCCN) 1969 The Assigned Control Connection ID AVP, Attribute Type AVP-TBA-3, 1970 contains the ID being assigned to this control connection by the 1971 sender. 1973 The Attribute Value field for this AVP has the following format: 1975 0 1 2 3 1976 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 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 | Assigned Control Connection ID | 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 The Assigned Control Connection ID is a 4-octet non-zero unsigned 1982 integer. 1984 The Assigned Control Connection ID AVP establishes the identifier 1985 used to multiplex and demultiplex multiple control connections 1986 between a pair of LCCEs. Once the Assigned Control Connection ID AVP 1987 has been received by an LCCE, the Control Connection ID specified in 1988 the AVP MUST be included in the Control Connection ID field of all 1989 control packets sent to the peer for the lifetime of the control 1990 connection. Before the Assigned Control Connection ID AVP is 1991 received from a peer, all control messages MUST be sent to that peer 1992 with a Control Connection ID value of 0 in the header. Because a 1993 Control Connection ID value of 0 is used in this special manner, the 1994 zero value MUST NOT be sent as an Assigned Control Connection ID 1995 value. 1997 Under certain circumstances, an LCCE may need to send a StopCCN to a 1998 peer without having yet received an Assigned Control Connection ID 1999 AVP from the peer (i.e. SCCRQ sent, no SCCRP received yet). In this 2000 case, the Assigned Control Connection ID AVP that had been sent to 2001 the peer earlier (i.e. in the SCCRQ) MUST be sent as the Assigned 2002 Control Connection ID AVP in the StopCCN. This policy allows the 2003 peer to try to identify the appropriate control connection via a 2004 reverse lookup. 2006 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2007 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2008 (before hiding) of this AVP is 10. 2010 Receive Window Size (SCCRQ, SCCRP) 2012 The Receive Window Size AVP, Attribute Type 10, specifies the receive 2013 window size being offered to the remote peer. 2015 The Attribute Value field for this AVP has the following format: 2017 0 1 2018 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 | Window Size | 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2023 The Window Size is a 2-octet unsigned integer. 2025 If absent, the peer must assume a Window Size of 4 for its transmit 2026 window. 2028 The remote peer may send the specified number of control messages 2029 before it must wait for an acknowledgment. See Section 4.2 for more 2030 information on reliable control message delivery. 2032 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 2033 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2034 Length of this AVP is 8. 2036 Pseudowire Capabilities List (SCCRQ, SCCRP) 2038 The Pseudowire Capabilities List (PW Capabilities List) AVP, 2039 Attribute Type AVP-TBA-4, indicates the L2 payload types the sender 2040 can support. The specific payload type of a given session is 2041 identified by the Pseudowire Type AVP. 2043 The Attribute Value field for this AVP has the following format: 2045 0 1 2 3 2046 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 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 | PW Type 0 | ... | 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2050 | ... | PW Type N | 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 Defined PW types that may appear in this list are managed by IANA and 2054 will appear in associated pseudowire-specific documents for each PW 2055 type. 2057 If a sender includes a given PW type in the PW Capabilities List AVP, 2058 the sender assumes full responsibility for supporting that particular 2059 payload, such as any payload-specific AVPs, L2-Specific Sublayer, or 2060 control messages that may be defined in the appropriate companion 2061 document. 2063 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2064 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2065 (before hiding) of this AVP is 8 octets with one PW type specified, 2066 plus 2 octets for each additional PW type. 2068 Preferred Language (SCCRQ, SCCRP) 2070 The Preferred Language AVP, Attribute Type AVP-TBD-14, provides a 2071 method for an LCCE to indicate to the peer the language in which 2072 human-readable messages it sends SHOULD be composed. This AVP 2073 contains a single language tag or language range [RFC3066]. 2075 The Attribute Value field for this AVP has the following format: 2077 0 1 2 3 2078 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 2079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2080 | Preferred Language... (arbitrary number of octets) 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2083 The Preferred Language is the indicated number of octets representing 2084 the language tag or language range, encoded in the US-ASCII charset. 2086 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2087 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2088 (before hiding) of this AVP is 6 plus the length of the Preferred 2089 Language. 2091 5.4.4 Session Management AVPs 2093 Local Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI) 2095 The Local Session ID AVP (analogous to the Assigned Session ID in 2096 L2TPv2), Attribute Type AVP-TBA-5, contains the identifier being 2097 assigned to this session by the sender. 2099 The Attribute Value field for this AVP has the following format: 2101 0 1 2 3 2102 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 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 | Local Session ID | 2105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 The Local Session ID is a 4-octet non-zero unsigned integer. 2109 The Local Session ID AVP establishes the two identifiers used to 2110 multiplex and demultiplex sessions between two LCCEs. Each LCCE 2111 chooses any free value it desires, and sends it to the remote LCCE 2112 using this AVP. The remote LCCE MUST then send all data packets 2113 associated with this session using this value. Additionally, for all 2114 session-oriented control messages sent after this AVP is received 2115 (e.g. ICRP, ICCN, CDN, SLI, etc.), the remote LCCE MUST echo this 2116 value in the Remote Session ID AVP. 2118 Note that a Session ID value is unidirectional. Because each LCCE 2119 chooses its Session ID independent of its peer LCCE, the value does 2120 not have to match in each direction for a given session. 2122 See Section 4.1 for additional information about the Session ID. 2124 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2125 AVP SHOULD be 1 set to 1, but MAY vary (see Section 5.2). The Length 2126 (before hiding) of this AVP is 10. 2128 Remote Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI) 2130 The Remote Session ID AVP, Attribute Type AVP-TBA-6, contains the 2131 identifier that was assigned to this session by the peer. 2133 The Attribute Value field for this AVP has the following format: 2135 0 1 2 3 2136 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 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 | Remote Session ID | 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 The Remote Session ID is a 4-octet non-zero unsigned integer. 2143 The Remote Session ID AVP MUST be present in all session-level 2144 control messages. The AVP's value echoes the session identifier 2145 advertised by the peer via the Local Session ID AVP. It is the same 2146 value that will be used in all transmitted data messages by this side 2147 of the session. In most cases, this identifier is sufficient for the 2148 peer to look up session-level context for this control message. 2150 When a session-level control message must be sent to the peer before 2151 the Local Session ID AVP has been received, the value of the Remote 2152 Sesson ID AVP MUST be set to zero. Additionally, the Local Session 2153 ID AVP (sent in a previous control message for this session) MUST be 2154 included in the control message. The peer must then use the Local 2155 Session ID AVP to perform a reverse lookup to find its session 2156 context. Session-level control messages defined in this document 2157 that might be subject to a reverse lookup by a receiving peer include 2158 the CDN, WEN, and SLI. 2160 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2161 AVP SHOULD be set to 1, but MAY vary (see Section 5, but MAY vary 2162 (see Section 5.2). The Length (before hiding) of this AVP is 10. 2164 Assigned Cookie (ICRQ, ICRP, OCRQ, OCRP) 2166 The Assigned Cookie AVP, Attribute Type AVP-TBA-7, contains the 2167 Cookie value being assigned to this session by the sender. 2169 The Attribute Value field for this AVP has the following format: 2171 0 1 2 3 2172 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 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | Assigned Cookie (32 or 64 bits) ... 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2177 The Assigned Cookie is a 4-octet or 8-octet random value. 2179 The Assigned Cookie AVP contains the value used to check the 2180 association of a received data message with the session identified by 2181 the Session ID. All data messages sent to a peer MUST use the 2182 Assigned Cookie sent by the peer in this AVP. The value's length (0, 2183 32, or 64 bits) is obtained by the Length of the AVP. 2185 A missing Assigned Cookie AVP or Assigned Cookie Value of zero length 2186 indicates that the Cookie field should not be present in any data 2187 packets sent to the LCCE sending this AVP. 2189 See Section 4.1 for additional information about the Assigned Cookie. 2191 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2192 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2193 (before hiding) of this AVP may be 6, 10, or 14 octets. 2195 Serial Number (ICRQ, OCRQ) 2197 The Serial Number AVP, Attribute Type 15, contains an identifier 2198 assigned by the LAC or LNS to this session. 2200 The Attribute Value field for this AVP has the following format: 2202 0 1 2 3 2203 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 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2205 | Serial Number | 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 The Serial Number is a 32-bit value. 2210 The Serial Number is intended to be an easy reference for 2211 administrators on both ends of a control connection to use when 2212 investigating session failure problems. Serial Numbers should be set 2213 to progressively increasing values, which are likely to be unique for 2214 a significant period of time across all interconnected LNSs and LACs. 2216 Note that in RFC 2661, this value was referred to as the "Call Serial 2217 Number AVP". It serves the same purpose and has the same attribute 2218 value and composition. 2220 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2221 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2222 (before hiding) of this AVP is 10. 2224 Remote End ID (ICRQ, OCRQ) 2226 The Remote End ID AVP, Attribute Type AVP-TBA-8, contains an 2227 identifier used to bind L2TP sessions to a given circuit, interface, 2228 or bridging instance. It also may be used to detect session-level 2229 ties. 2231 The Attribute Value field for this AVP has the following format: 2233 0 1 2 3 2234 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 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 | Remote End Identifier ... (arbitrary number of octets) 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 The Remote End Identifier field is a variable-length field whose 2240 value is unique for a given LCCE peer, as described in Section 3.3. 2242 A session-level tie is detected if an LCCE receives an ICRQ or OCRQ 2243 with an End ID AVP whose value matches that which was just sent in an 2244 outgoing ICRQ or OCRQ to the same peer. If the two values match, an 2245 LCCE recognizes that a tie exists (e.g. both LCCEs are attempting to 2246 establish sessions for the same circuit). The tie is broken by the 2247 Session Tie Breaker AVP. 2249 By default, the LAC-LAC cross-connect application (see section 2250 2.0(b)) of L2TP over an IP network MUST utilize the Router ID AVP and 2251 Remote End ID AVP to associate a circuit to an L2TP session. Other 2252 AVPs MAY be used for LCCE or circuit identification as specified in 2253 companion documents. 2255 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2256 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2257 (before hiding) of this AVP is 6 plus the length of the Remote End 2258 Identifier value. 2260 Application Code (ICRQ, OCRQ) 2262 The Application Code AVP, Attribute Type AVP-TBA-9, is a 2 octet 2263 value for enumerating application types for a given L2TP session. 2265 The Attribute Value field for this AVP has the following format: 2267 0 1 2268 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 2269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2270 | Application Code | 2271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 The Application Code is a 2 octet value used to identify a specific 2274 application for an L2TP session, perhaps causing certain values 2275 within AVPs defined in this document to be interpreted or acted upon 2276 in a different manner dictated by the Application Code. For example, 2277 a given Application Code could instruct an LCCE to perform a specific 2278 directory lookup on the Hostname and/or Router ID AVP information 2279 associated with this session (perhaps even encoding the destination 2280 address of the given directory server). 2282 An Application Code of 0, or absence of this AVP in any control 2283 message, indicates that all AVPs should be interpreted as defined in 2284 this document. 2286 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2287 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2288 (before hiding) of this AVP is 8. 2290 Session Tie Breaker (ICRQ, OCRQ) 2292 The Session Tie Breaker AVP, Attribute Type TBD, is used to break 2293 ties when two peers concurrently attempt to establish a session for 2294 the same circuit. 2296 The Attribute Value field for this AVP has the following format: 2298 0 1 2 3 2299 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 2300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2301 | Session Tie Breaker Value ... 2302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2303 ... (64 bits) | 2304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2306 The Session Tie Breaker Value is an 8-octet random value that is used 2307 to choose a session when two LCCEs concurrently request a session for 2308 the same circuit. A tie is detected by examining the peer's identity 2309 (described in Section 3.3) plus the per-session shared value 2310 communicated via the End ID AVP. In the case of a tie, the recipient 2311 of an ICRQ or OCRQ must compare the received tie breaker value with 2312 the one that it sent earlier. The LCCE with the lower value "wins", 2313 and the "loser" MUST send a CDN with result code set to RC-TBA-1 (as 2314 defined in Section 5.4.2) to tear down the session it instigated. In 2315 the case in which a tie is detected, tie breakers are sent by both 2316 sides, and the tie breaker values are equal, both sides MUST discard 2317 their sessions and restart session negotiation with new random tie 2318 breaker values. 2320 If a tie is detected but only one side sends a Session Tie Breaker 2321 AVP, the session initiator that included the Session Tie Breaker AVP 2322 "wins". If neither side issues a tie breaker, then both sides MUST 2323 tear down the session. 2325 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this 2326 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length of 2327 this AVP is 14. 2329 Pseudowire Type (ICRQ, OCRQ) 2331 The Pseudowire Type (PW Type) AVP, Attribute Type AVP-TBA-10, 2332 indicates the L2 payload type of the packets that will be tunneled 2333 using this L2TP session. 2335 The Attribute Value field for this AVP has the following format: 2337 0 1 2338 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 | PW Type | 2341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2343 A peer MUST NOT request an incoming or outgoing call with a PW Type 2344 AVP specifying a value not advertised in the PW Capabilities List AVP 2345 it received during control connection establishment. Attempts to do 2346 so MUST result in the call being rejected via a CDN with the Result 2347 Code set to RC-TBA-2 (see Section 5.4.2). 2349 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2350 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2351 (before hiding) of this AVP is 8. 2353 L2-Specific Sublayer (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2355 The L2-Specific Sublayer AVP, Attribute Type AVP-TBA-11, indicates 2356 the the presence and format of the L2-Specific Sublayer the sender of 2357 this AVP requires on all incoming data packets for this L2TP session. 2359 0 1 2360 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2362 | L2-Specific Sublayer Type | 2363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2365 The L2-Specific Sublayer Type is a 2-octet unsigned integer with the 2366 following values defined in this document: 2368 0 - There is no L2-Specific Sublayer present. 2369 1 - The default L2-Specific Sublayer (defined in Section 4.6) 2370 is used. 2372 If this AVP is received and has a value other than zero, the 2373 receiving LCCE MUST include the identified L2-Specific Sublayer in 2374 its outgoing data messages. If the AVP is not received, it is 2375 assumed that there is no sublayer present. 2377 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2378 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2379 (before hiding) of this AVP is 8. 2381 Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2383 The Data Sequencing AVP, Attribute Type AVP-TBA-12, indicates that 2384 the sender requires some or all of the data packets that it receives 2385 to be sequenced. 2387 The Attribute Value field for this AVP has the following format: 2389 0 1 2390 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 | Data Sequencing Level | 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 The Data Sequencing Level is a 2-octet unsigned integer indicating 2396 the degree of incoming data traffic that the sender of this AVP 2397 wishes to be marked with sequence numbers. 2399 The following values are valid data sequencing levels: 2401 0 - No incoming data packets require sequencing. 2402 1 - Only non-IP data packets require sequencing. 2403 2 - All incoming data packets require sequencing. 2405 If a data sequencing level of 0 is specified, there is no need to 2406 send packets with sequence numbers. If sequence numbers are sent, 2407 they will be ignored upon receipt. If no Data Sequencing AVP is 2408 received, a data sequencing level of 0 is assumed. 2410 If a data sequencing level of 1 is specified, only non-IP traffic 2411 carried within the tunneled L2 frame should have sequence numbers 2412 applied. Non-IP traffic here refers to any packets that cannot be 2413 classified as an IP packet within their respective L2 framing (i.e., 2414 a PPP control packet or NETBIOS frame encapsulated by Frame Relay 2415 before being tunneled). All traffic that can be classified as IP MUST 2416 be sent with no sequencing (e.g. the S bit in the L2-Specific 2417 Sublayer is set to zero). If a packet is unable to be classified at 2418 all (e.g. due to it being compressed or encrypted at layer 2) or if 2419 an implementation is unable to perform such classification within L2 2420 frames, all packets MUST be provided with sequence numbers 2421 (essentially falling back to a data sequencing level of 2). 2423 If a data sequencing level of 2 is specified, all traffic MUST be 2424 sequenced. 2426 Data sequencing may only be requested when there is an L2-Specific 2427 Sublayer present that can provide sequence numbers. If sequencing is 2428 requested without requesting a L2-Specific Sublayer AVP, the session 2429 MUST be disconnected with a Result Code of RC-TBA-3. 2431 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2432 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2433 (before hiding) of this AVP is 6. 2435 Tx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2437 The Tx Connect Speed BPS AVP, Attribute Type 24, contains the speed 2438 of the facility chosen for the connection attempt. 2440 The Attribute Value field for this AVP has the following format: 2442 0 1 2 3 2443 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 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 | Tx Connect Speed BPS | 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2448 The Tx Connect Speed BPS is a 4-octet value indicating the speed in 2449 bits per second. A value of zero indicates that the speed is 2450 indeterminable or that there is no physical point-to-point link. 2452 When the optional Rx Connect Speed AVP is present, the value in this 2453 AVP represents the transmit connect speed from the perspective of the 2454 LAC (e.g. data flowing from the LAC to the remote system). When the 2455 optional Rx Connect Speed AVP is NOT present, the connection speed 2456 between the remote system and LAC is assumed to be symmetric and is 2457 represented by the single value in this AVP. 2459 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2460 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2461 (before hiding) of this AVP is 10. 2463 Rx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2465 The Rx Connect Speed AVP, Attribute Type 38, represents the speed of 2466 the connection from the perspective of the LAC (e.g. data flowing 2467 from the remote system to the LAC). 2469 The Attribute Value field for this AVP has the following format: 2471 0 1 2 3 2472 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 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2474 | Rx Connect Speed BPS | 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 Rx Connect Speed BPS is a 4-octet value indicating the speed in bits 2478 per second. A value of zero indicates that the speed is 2479 indeterminable or that there is no physical point-to-point link. 2481 Presence of this AVP implies that the connection speed may be 2482 asymmetric with respect to the transmit connect speed given in the Tx 2483 Connect Speed AVP. 2485 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2486 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2487 (before hiding) of this AVP is 10. 2489 Physical Channel ID (ICRQ, ICRP, OCRP) 2491 The Physical Channel ID AVP, Attribute Type 25, contains the vendor- 2492 specific physical channel number used for a call. 2494 The Attribute Value field for this AVP has the following format: 2496 0 1 2 3 2497 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 2498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2499 | Physical Channel ID | 2500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2502 Physical Channel ID is a 4-octet value intended to be used for 2503 logging purposes only. 2505 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2506 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2507 (before hiding) of this AVP is 10. 2509 5.4.5 Circuit Status AVPs 2511 Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI) 2513 The Circuit Status AVP, Attribute Type AVP-TBA-13, indicates the 2514 initial status of or a status change in the circuit to which the 2515 session is bound. 2517 The Attribute Value field for this AVP has the following format: 2519 0 1 2520 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 | Reserved |N|A| 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 The A (Active) bit indicates whether the circuit is up/active/ready 2526 (1) or down/inactive/not-ready (0). 2528 The N (New) bit indicates whether the circuit status indication is 2529 for a new circuit (1) or an existing circuit (0). Links which have a 2530 similar mechanism available (e.g. Frame Relay) MUST map the setting 2531 of this bit to the associated signaling for that link. Otherwise, the 2532 New bit SHOULD still be set the first time the L2TP session is 2533 established after provisioning. 2535 The remaining bits are reserved for future use. Reserved bits MUST 2536 be set to 0 when sending and ignored upon receipt. 2538 The Circuit Status AVP is used to advertise whether a circuit or 2539 interface bound to an L2TP session is up and ready to send and/or 2540 receive traffic. Different circuit types have different names for 2541 status types. For example, HDLC primary and secondary stations refer 2542 to a circuit as being "Receive Ready" or "Receive Not Ready", while 2543 Frame Relay refers to a circuit as "Active" or "Inactive". This AVP 2544 adopts the latter terminology, though the concept remains the same 2545 regardless of the PW type for the L2TP session. 2547 In the simplest case, the circuit referred by this AVP is a single 2548 physical interface, port, or circuit depending on application and how 2549 the session was setup. The status indication in this AVP may then be 2550 used to provide simple ILMI interworking for a variety of circuit 2551 types. For virtual or multipoint interfaces, the Circuit Status AVP 2552 is still utilized, but effectively refers to the state of an internal 2553 structure or a logical set of circuits. Each PW-specific companion 2554 document MUST then specify precisely how this AVP is translated for 2555 each circuit type. 2557 If this AVP is received with a Not Active notification for a given 2558 L2TP session, all data traffic for that session MUST cease (or not 2559 begin) in the direction of the sender of the Circuit Status AVP until 2560 the circuit is advertised as Active. 2562 The Circuit Status MUST be advertised by this AVP in ICRQ, ICRP, 2563 OCRQ, and OCRP messages. Often, the circuit type will be marked 2564 Active when initiated, but MAY be advertised as Inactive, indicating 2565 that an L2TP session is to be created but that the interface or 2566 circuit is still not ready to pass traffic. The ICCN, OCCN, and SLI 2567 control messages all MAY contain this AVP to update the status of the 2568 circuit after establishment of the L2TP session is requested. 2570 If additional circuit status information is needed for a given PW 2571 type, PW-specific AVPs MUST be defined in a separate document for 2572 that information. This AVP is only for general circuit status 2573 information applicable to all circuit/interface types. 2575 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2576 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2577 (before hiding) of this AVP is 8. 2579 Circuit Errors (WEN) 2581 The Circuit Errors AVP, Attribute Type 34, conveys circuit error 2582 information to the peer. 2584 The Attribute Value field for this AVP has the following format: 2586 0 1 2 3 2587 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 2588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2589 | Reserved | 2590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2591 | Hardware Overruns | 2592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2593 | Buffer Overruns | 2594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2595 | Timeout Errors | 2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2597 | Alignment Errors | 2598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2600 The following fields are defined: 2602 Reserved: 2 octets of Reserved data is present (providing longword 2603 alignment within the AVP of the following values). Reserved 2604 data MUST be zero on sending and ignored upon receipt. 2605 Hardware Overruns: Number of receive buffer overruns since call 2606 was established. 2607 Buffer Overruns: Number of buffer overruns detected since call was 2608 established. 2609 Timeout Errors: Number of timeouts since call was established. 2610 Alignment Errors: Number of alignment errors since call was 2611 established. 2613 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2614 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2615 (before hiding) of this AVP is 32. 2617 6. Control Connection Protocol Specification 2619 The following control messages are used to establish, maintain, and 2620 tear down L2TP control connections. All data packets are sent in 2621 network order (high-order octets first). Any "reserved" or "empty" 2622 fields MUST be sent as 0 values to allow for protocol extensibility. 2624 The exchanges in which these messages are involved are outlined in 2625 Section 3.3. 2627 6.1 Start-Control-Connection-Request (SCCRQ) 2629 Start-Control-Connection-Request (SCCRQ) is a control message used to 2630 initiate a control connection between two LCCEs. It is sent by 2631 either the LAC or the LNS to begin the control connection 2632 establishment process. 2634 The following AVPs MUST be present in the SCCRQ: 2636 Message Type 2637 Host Name 2638 Router ID 2639 Assigned Control Connection ID 2640 Pseudowire Capabilities List 2642 The following AVPs MAY be present in the SCCRQ: 2644 Random Vector 2645 Nonce 2646 Message Digest 2647 Control Connection Tie Breaker 2648 Vendor Name 2649 Receive Window Size 2650 Preferred Language 2652 6.2 Start-Control-Connection-Reply (SCCRP) 2654 Start-Control-Connection-Reply (SCCRP) is the control message sent in 2655 reply to a received SCCRQ message. The SCCRP is used to indicate 2656 that the SCCRQ was accepted and establishment of the control 2657 connection should continue. 2659 The following AVPs MUST be present in the SCCRP: 2661 Message Type 2662 Host Name 2663 Router ID 2664 Assigned Control Connection ID 2665 Pseudowire Capabilities List 2667 The following AVPs MAY be present in the SCCRP: 2669 Random Vector 2670 Nonce 2671 Message Digest 2672 Vendor Name 2673 Receive Window Size 2674 Preferred Language 2676 6.3 Start-Control-Connection-Connected (SCCCN) 2678 Start-Control-Connection-Connected (SCCCN) is the control message 2679 sent in reply to an SCCRP. The SCCCN completes the control 2680 connection establishment process. 2682 The following AVP MUST be present in the SCCCN: 2684 Message Type 2686 The following AVP MAY be present in the SCCCN: 2688 Random Vector 2689 Message Digest 2691 6.4 Stop-Control-Connection-Notification (StopCCN) 2693 Stop-Control-Connection-Notification (StopCCN) is the control message 2694 sent by either LCCE to inform its peer that the control connection is 2695 being shut down and that the control connection should be closed. In 2696 addition, all active sessions are implicitly cleared (without sending 2697 any explicit session control messages). The reason for issuing this 2698 request is indicated in the Result Code AVP. There is no explicit 2699 reply to the message, only the implicit ACK that is received by the 2700 reliable control message delivery layer. 2702 The following AVPs MUST be present in the StopCCN: 2704 Message Type 2705 Result Code 2707 The following AVPs MAY be present in the StopCCN: 2709 Random Vector 2710 Message Digest 2711 Assigned Control Connection ID 2713 Note that the Assigned Control Connection ID MUST be present if the 2714 StopCCN is sent after an SCCRQ or SCCRP message has been sent. 2716 6.5 Hello (HELLO) 2718 The Hello (HELLO) message is an L2TP control message sent by either 2719 peer of a control connection. This control message is used as a 2720 "keepalive" for the control connection. See Section 4.2 for a 2721 description of the keepalive mechanism. 2723 HELLO messages are global to the control connection. The Session ID 2724 in a HELLO message MUST be 0. 2726 The following AVP MUST be present in the HELLO: 2728 Message Type 2730 The following AVP MAY be present in the HELLO: 2732 Random Vector 2733 Message Digest 2735 6.6 Incoming-Call-Request (ICRQ) 2737 Incoming-Call-Request (ICRQ) is the control message sent by an LCCE 2738 to a peer when an incoming call is detected (although the ICRQ may 2739 also be sent as a result of a local event). It is the first in a 2740 three-message exchange used for establishing a session via an L2TP 2741 control connection. 2743 The ICRQ is used to indicate that a session is to be established 2744 between an LCCE and a peer. The sender of an ICRQ provides the peer 2745 with parameter information for the session. However, the sender 2746 makes no demands about how the session is terminated at the peer 2747 (i.e. whether the L2 traffic is processed locally, forwarded, etc.). 2749 The following AVPs MUST be present in the ICRQ: 2751 Message Type 2752 Local Session ID 2753 Remote Session ID 2754 Serial Number 2755 Pseudowire Type 2756 Circuit Status 2758 The following AVPs MAY be present in the ICRQ: 2760 Random Vector 2761 Message Digest 2762 Assigned Cookie 2763 Remote End ID 2764 Application ID 2765 Session Tie Breaker 2766 L2-Specific Sublayer 2767 Data Sequencing 2768 Tx Connect Speed 2769 Rx Connect Speed 2770 Physical Channel ID 2772 6.7 Incoming-Call-Reply (ICRP) 2774 Incoming-Call-Reply (ICRP) is the control message sent by an LCCE in 2775 response to a received ICRQ. It is the second in the three-message 2776 exchange used for establishing sessions within an L2TP control 2777 connection. 2779 The ICRP is used to indicate that the ICRQ was successful and that 2780 the peer should establish (i.e. answer) the incoming call if it has 2781 not already done so. It also allows the sender to indicate specific 2782 parameters about the L2TP session. 2784 The following AVPs MUST be present in the ICRP: 2786 Message Type 2787 Local Session ID 2788 Remote Session ID 2789 Circuit Status 2791 The following AVPs MAY be present in the ICRP: 2793 Random Vector 2794 Message Digest 2795 Assigned Cookie 2796 L2-Specific Sublayer 2797 Data Sequencing 2798 Tx Connect Speed 2799 Rx Connect Speed 2800 Physical Channel ID 2802 6.8 Incoming-Call-Connected (ICCN) 2804 Incoming-Call-Connected (ICCN) is the control message sent by the 2805 LCCE that originally sent an ICRQ upon receiving an ICRP from its 2806 peer. It is the final message in the three-message exchange used for 2807 establishing L2TP sessions. 2809 The ICCN is used to indicate that the ICRP was accepted, that the 2810 call has been established, and that the L2TP session should move to 2811 the established state. It also allows the sender to indicate 2812 specific parameters about the established call (parameters that may 2813 not have been available at the time the ICRQ is issued). 2815 The following AVPs MUST be present in the ICCN: 2817 Message Type 2818 Local Session ID 2819 Remote Session ID 2821 The following AVPs MAY be present in the ICCN: 2823 Random Vector 2824 Message Digest 2825 L2-Specific Sublayer 2826 Data Sequencing 2827 Tx Connect Speed 2828 Rx Connect Speed 2829 Circuit Status 2831 6.9 Outgoing-Call-Request (OCRQ) 2833 Outgoing-Call-Request (OCRQ) is the control message sent by an LCCE 2834 to an LAC to indicate that an outbound call at the LAC is to be 2835 established based on specific destination information sent in this 2836 message. It is the first in a three-message exchange used for 2837 establishing a session and placing a call on behalf of the initiating 2838 LCCE. 2840 Note that a call may be any L2 connection requiring well-known 2841 destination information to be sent from an LCCE to an LAC. This call 2842 could be a dialup connection to the PSTN, an SVC connection, the IP 2843 address of another LCCE, or any other destination dictated by the 2844 sender of this message. 2846 The following AVPs MUST be present in the OCRQ: 2848 Message Type 2849 Local Session ID 2850 Remote Session ID 2851 Serial Number 2852 Pseudowire Type 2853 Circuit Status 2855 The following AVPs MAY be present in the OCRQ: 2857 Random Vector 2858 Message Digest 2859 Assigned Cookie 2860 Remote End ID 2861 Application ID 2862 Tx Connect Speed 2863 Rx Connect Speed 2864 Session Tie Breaker 2865 L2-Specific Sublayer 2866 Data Sequencing 2868 6.10 Outgoing-Call-Reply (OCRP) 2870 Outgoing-Call-Reply (OCRP) is the control message sent by an LAC to 2871 an LCCE in response to a received OCRQ. It is the second in a 2872 three-message exchange used for establishing a session within an L2TP 2873 control connection. 2875 OCRP is used to indicate that the LAC has been able to attempt the 2876 outbound call. The message returns any relevant parameters regarding 2877 the call attempt. Data MUST NOT be forwarded until the OCCN is 2878 received indicating that the call has been placed. 2880 The following AVPs MUST be present in the OCRP: 2882 Message Type 2883 Local Session ID 2884 Remote Session ID 2885 Circuit Status 2887 The following AVPs MAY be present in the OCRP: 2889 Random Vector 2890 Message Digest 2891 Assigned Cookie 2892 L2-Specific Sublayer 2893 Tx Connect Speed 2894 Rx Connect Speed 2895 Data Sequencing 2896 Physical Channel ID 2898 6.11 Outgoing-Call-Connected (OCCN) 2900 Outgoing-Call-Connected (OCCN) is the control message sent by an LAC 2901 to another LCCE after the OCRP and after the outgoing call has been 2902 completed. It is the final message in a three-message exchange used 2903 for establishing a session. 2905 OCCN is used to indicate that the result of a requested outgoing call 2906 was successful. It also provides information to the LCCE who 2907 requested the call about the particular parameters obtained after the 2908 call was established. 2910 The following AVPs MUST be present in the OCCN: 2912 Message Type 2913 Local Session ID 2914 Remote Session ID 2916 The following AVPs MAY be present in the OCCN: 2918 Random Vector 2919 Message Digest 2920 L2-Specific Sublayer 2921 Tx Connect Speed 2922 Rx Connect Speed 2923 Data Sequencing 2924 Circuit Status 2926 6.12 Call-Disconnect-Notify (CDN) 2928 The Call-Disconnect-Notify (CDN) is a control message sent by an LCCE 2929 to request disconnection of a specific session. Its purpose is to 2930 inform the peer of the disconnection and the reason for the 2931 disconnection. The peer MUST clean up any resources, and does not 2932 send back any indication of success or failure for such cleanup. 2934 The following AVPs MUST be present in the CDN: 2936 Message Type 2937 Result Code 2938 Local Session ID 2939 Remote Session ID 2941 The following AVP MAY be present in the CDN: 2943 Random Vector 2944 Message Digest 2946 6.13 WAN-Error-Notify (WEN) 2948 The WAN-Error-Notify (WEN) is a control message sent from an LAC to an 2949 LNS to indicate WAN error conditions. The counters in this message 2950 are cumulative. This message should only be sent when an error 2951 occurs, and not more than once every 60 seconds. The counters are 2952 reset when a new call is established. 2954 The following AVPs MUST be present in the WEN: 2956 Message Type 2957 Local Session ID 2958 Remote Session ID 2959 Circuit Errors 2961 The following AVP MAY be present in the WEN: 2963 Random Vector 2964 Message Digest 2966 6.14 Set-Link-Info (SLI) 2968 The Set-Link-Info control message is sent by an LCCE to convey link 2969 or circuit status change information regarding the circuit associated 2970 with this L2TP session. For example, if PPP renegotiates LCP at an 2971 LNS or between an LAC and a Remote System, or if a forwarded Frame 2972 Relay VC transitions to Active or Inactive at an LAC, an SLI message 2973 SHOULD be sent to indicate this event. Precise details of when the 2974 SLI is sent, what PW type-specific AVPs must be present, and how 2975 those AVPs should be interpreted by the receiving peer are outside 2976 the scope of this document. These details should be described in the 2977 associated pseudowire-specific documents that require use of this 2978 message. 2980 The following AVPs MUST be present in the SLI: 2982 Message Type 2983 Local Session ID 2984 Remote Session ID 2986 The following AVPs MAY be present in the SLI: 2988 Random Vector 2989 Message Digest 2990 Circuit Status 2992 6.15 Explicit-Acknowledgement (ACK) 2994 The Explicit Acknowledgement (ACK) message is used only to 2995 acknowledge receipt of a message or messages on the Control 2996 Connection (e.g. for purposes of updating Ns and Nr values). Receipt 2997 of this message does not trigger an event for the L2TP protocol state 2998 machine. 3000 A message received without any AVPs (including the Message Type AVP), 3001 is referred to as a Zero Length Body (ZLB) message, and serves the 3002 same function as the Explicit Acknowledgement. ZLB messages are only 3003 permitted when the Control Message Authentication defined in Section 3004 4.3 is not enabled. 3006 The following AVPs MAY be present in the ACK message: 3008 Message Type 3009 Message Digest 3010 mi.sp 3011 7. Control Connection State Machines 3013 The state tables defined in this section govern the exchange of 3014 control messages defined in Section 6. Tables are defined for 3015 incoming call placement and outgoing call placement, as well as for 3016 initiation of the control connection itself. The state tables do not 3017 encode message timeout and retransmission behavior, as this is 3018 handled in the underlying reliable control message delivery mechanism 3019 (see Section 4.2). 3021 Timers MAY be employed to enforce a maximum period of time allowed in 3022 a transitional state (i.e. between idle and established). Generally, 3023 this is a protection mechanism for cleaning up state when an error 3024 has occurred, and should be treated as such. The precise period of 3025 time to wait is application dependent and MUST be configurable, with 3026 the notable default of no timeout at all. If a session is shutdown 3027 by a state transition timeout, a CDN MUST be sent with a Result Code 3028 set to RC-TBA-4 (see Section 5.4.2). If a control connection is 3029 shutdown by a state transition timeout, a StopCCN MUST be sent with a 3030 Result Code set to 7 (see Section 5.4.2). 3032 7.1 Malformed Control Messages 3034 Receipt of an invalid or unrecoverable malformed control message 3035 SHOULD be logged appropriately and the control connection cleared to 3036 ensure recovery to a known state. The control connection may then be 3037 restarted by the initiator. An invalid control message is defined as 3038 (1) a message that contains a Message Type marked as mandatory (see 3039 Section 5.4.1) but that is unknown to the implementation, or (2) a 3040 control message that is received in the wrong state. 3042 Examples of malformed control messages include (1) a message that has 3043 an invalid value in its header, (2) a message that contains an AVP 3044 that is formatted incorrectly or whose value is out of range, and (3) 3045 a message that is missing a required AVP. A control message with a 3046 malformed header MUST be discarded. 3048 If a malformed AVP is received with the M bit set, the session or 3049 control connection MUST be terminated with a proper Result or Error 3050 Code sent (see Section 5.2). A malformed yet non-mandatory (M bit is 3051 not set) AVP within a control message should be handled like an 3052 unrecognized non-mandatory AVP. That is, the AVP MUST be ignored 3053 (with the exception of logging a local error message), and the 3054 message MUST be accepted. 3056 It is impossible to list all potential malformations of a given 3057 message. However, an example of a recoverable, malformed AVP might 3058 be if the Rx Connect Speed AVP, attribute 38, is received with a 3059 length of 8 rather than 10, and the BPS given in 2 octets rather than 3060 4. In the Rx Connect Speed is sent with the M bit set to 0, this 3061 malformation should not be considered catastrophic. As such, the 3062 control message should be accepted as if the AVP had not been 3063 received (with the exception of a local error message being logged). 3064 This example is by no means a license to create malformed AVPs, but 3065 simply a guideline for how liberal one should be in acceptance of 3066 messages containing errors. 3068 In the following tables, there are several cases where a protocol 3069 message is sent and then a "clean up" occurs. Note that, regardless 3070 of the initiator of the control connection shutdown, the reliable 3071 delivery mechanism must be allowed to run (see Section 4.2) before 3072 destroying the control connection. This permits the control 3073 connection management messages to be reliably delivered to the peer. 3075 Appendix B.1 contains an example of lock-step control connection 3076 establishment. 3078 7.2 Control Connection States 3080 The L2TP control connection protocol is not distinguishable between 3081 the two LCCEs but is distinguishable between the originator and 3082 receiver. The originating peer is the one that first initiates 3083 establishment of the control connection. (In a tie breaker 3084 situation, this is the winner of the tie.) Since either the LAC or 3085 the LNS can be the originator, a collision can occur. See the 3086 Control Connection Tie Breaker AVP in Section 5.4.3 for a description 3087 of this and its resolution. 3089 State Event Action New State 3090 ----- ----- ------ --------- 3091 idle Local open Send SCCRQ wait-ctl-reply 3092 request 3094 idle Receive SCCRQ, Send SCCRP wait-ctl-conn 3095 acceptable 3097 idle Receive SCCRQ, Send StopCCN, idle 3098 not acceptable clean up 3100 idle Receive SCCRP Send StopCCN, idle 3101 clean up 3103 idle Receive SCCCN Send StopCCN, idle 3104 clean up 3105 wait-ctl-reply Receive SCCRP, Send SCCCN, established 3106 acceptable send control-conn 3107 open event to 3108 waiting sessions 3110 wait-ctl-reply Receive SCCRP, Send StopCCN, idle 3111 not acceptable clean up 3113 wait-ctl-reply Receive SCCRQ, Send SCCRP, wait-ctl-conn 3114 lose tie breaker, Clean up losing 3115 SCCRQ acceptable connection 3117 wait-ctl-reply Receive SCCRQ, Send StopCCN, idle 3118 lose tie breaker, Clean up losing 3119 SCCRQ unacceptable connection 3121 wait-ctl-reply Receive SCCRQ, Send StopCCN for wait-ctl-reply 3122 win tie breaker losing connection 3124 wait-ctl-reply Receive SCCCN Send StopCCN, idle 3125 clean up 3127 wait-ctl-conn Receive SCCCN, Send control-conn established 3128 acceptable open event to 3129 waiting sessions 3131 wait-ctl-conn Receive SCCCN, Send StopCCN, idle 3132 not acceptable clean up 3134 wait-ctl-conn Receive SCCRP, Send StopCCN, idle 3135 SCCRQ clean up 3137 established Local open Send control-conn established 3138 request open event to 3139 (new call) waiting sessions 3141 established Administrative Send StopCCN, idle 3142 control-conn clean up 3143 close event 3145 established Receive SCCRQ, Send StopCCN, idle 3146 SCCRP, SCCCN clean up 3148 idle, Receive StopCCN Clean up idle 3149 wait-ctl-reply, 3150 wait-ctl-conn, 3151 established 3153 The states associated with an LCCE for control connection 3154 establishment are as follows: 3156 idle 3157 Both initiator and recipient start from this state. An initiator 3158 transmits an SCCRQ, while a recipient remains in the idle state 3159 until receiving an SCCRQ. 3161 wait-ctl-reply 3162 The originator checks to see if another connection has been 3163 requested from the same peer, and if so, handles the collision 3164 situation described in Section 5.4.3. 3166 wait-ctl-conn 3167 Awaiting an SCCCN. Upon receipt, the challenge response contained 3168 in the message is checked. The control connection is established 3169 if authentication succeeds; otherwise, it is torn down. 3171 established 3172 An established connection may be terminated by either a local 3173 condition or the receipt of a StopCCN. In the event of a local 3174 termination, the originator MUST send a StopCCN and clean up the 3175 control connection. If the originator receives a StopCCN, it MUST 3176 also clean up the control connection. 3178 7.3 Incoming Calls 3180 An ICRQ is generated by an LCCE, typically in response to an incoming 3181 call or a local event. Once the LCCE sends the ICRQ, it waits for a 3182 response from the peer. However, it may choose to postpone 3183 establishment of the call (e.g. answering the call, bringing up the 3184 circuit) until the peer has indicated with an ICRP that it will 3185 accept the call. The peer may choose not to accept the call if, for 3186 instance, there are insufficient resources to handle an additional 3187 session. 3189 If the peer chooses to accept the call, it responds with an ICRP. 3190 When the local LCCE receives the ICRP, it attempts to establish the 3191 call. A final call connected message, the ICCN, is sent from the 3192 local LCCE to the peer to indicate that the call states for both 3193 LCCEs should enter the established state. If the call is terminated 3194 before the peer can accept it, a CDN is sent by the local LCCE to 3195 indicate this condition. 3197 When a call transitions to a "disconnected" or "down" state, the call 3198 is cleared normally, and the local LCCE sends a CDN. Similarly, if 3199 the peer wishes to clear a call, it sends a CDN and cleans up its 3200 session. 3202 7.3.1 ICRQ Sender States 3204 State Event Action New State 3205 ----- ----- ------ --------- 3207 idle Call signal or Initiate local wait-control-conn 3208 ready to receive control-conn 3209 incoming conn open 3211 idle Receive ICCN, Clean up idle 3212 ICRP, CDN 3214 wait-control- Bearer line drop Clean up idle 3215 conn or local close 3216 request 3218 wait-control- control-conn-open Send ICRQ wait-reply 3219 conn 3221 wait-reply Receive ICRP, Send ICCN established 3222 acceptable 3224 wait-reply Receive ICRP, Send CDN, idle 3225 Not acceptable clean up 3227 wait-reply Receive ICRQ, Process as idle 3228 lose tie breaker ICRQ Recipient 3229 (Section 7.3.2) 3231 wait-reply Receive ICRQ, Send CDN wait-reply 3232 win tie breaker for losing 3233 session 3235 wait-reply Receive CDN, Clean up idle 3236 ICCN 3238 wait-reply Local close Send CDN, idle 3239 request clean up 3241 established Receive CDN Clean up idle 3243 established Receive ICRQ, Send CDN, idle 3244 ICRP, ICCN clean up 3246 established Local close Send CDN, idle 3247 request clean up 3249 The states associated with the ICRQ sender are as follows: 3251 idle 3252 The LCCE detects an incoming call on one of its interfaces (e.g. 3253 an analog PSTN line rings, or an ATM PVC is provisioned), or a 3254 local event occurs. The LCCE initiates its control connection 3255 establishment state machine and moves to a state waiting for 3256 confirmation of the existence of a control connection. 3258 wait-control-conn 3259 In this state, the session is waiting for either the control 3260 connection to be opened or for verification that the control 3261 connection is already open. Once an indication that the control 3262 connection has been opened is received, session control messages 3263 may be exchanged. The first of these messages is the ICRQ. 3265 wait-reply 3266 The ICRQ sender receives either (1) a CDN indicating the peer is 3267 not willing to accept the call (general error or do not accept) 3268 and moves back into the idle state, or (2) an ICRP indicating the 3269 call is accepted. In the latter case, the LCCE sends an ICCN and 3270 enters the established state. 3272 established 3273 Data is exchanged over the session. The call may be cleared by 3274 any of the following: 3275 + An event on the connected interface: The LCCE sends a CDN. 3276 + Receipt of a CDN: The LCCE cleans up, disconnecting the call. 3277 + A local reason: The LCCE sends a CDN. 3279 7.3.2 ICRQ Recipient States 3281 State Event Action New State 3282 ----- ----- ------ --------- 3283 idle Receive ICRQ, Send ICRP wait-connect 3284 acceptable 3286 idle Receive ICRQ, Send CDN, idle 3287 not acceptable clean up 3289 idle Receive ICRP Send CDN idle 3290 clean up 3292 idle Receive ICCN Clean up idle 3294 wait-connect Receive ICCN Prepare for established 3295 acceptable data 3297 wait-connect Receive ICCN Send CDN, idle 3298 not acceptable clean up 3300 wait-connect Receive ICRQ, Send CDN, idle 3301 ICRP clean up 3303 idle, Receive CDN Clean up idle 3304 wait-connect, 3305 established 3307 wait-connect Local close Send CDN, idle 3308 established request clean up 3310 established Receive ICRQ, Send CDN, idle 3311 ICRP, ICCN clean up 3313 The states associated with the ICRQ recipient are as follows: 3315 idle 3316 An ICRQ is received. If the request is not acceptable, a CDN is 3317 sent back to the peer LCCE, and the local LCCE remains in the idle 3318 state. If the ICRQ is acceptable, an ICRP is sent. The session 3319 moves to the wait-connect state. 3321 wait-connect 3322 The local LCCE is waiting for an ICCN from the peer. Upon receipt 3323 of the ICCN, the local LCCE moves to established state. 3325 established 3326 The session is terminated either by sending a CDN or by receiving 3327 a CDN from the peer. Clean up follows on both sides regardless of 3328 the initiator. 3330 7.4 Outgoing Calls 3332 Outgoing calls instruct an LAC to place a call. There are three 3333 messages for outgoing calls: OCRQ, OCRP, and OCCN. An LCCE first 3334 sends an OCRQ to an LAC to request an outgoing call. The LAC MUST 3335 respond to the OCRQ with an OCRP once it determines that the proper 3336 facilities exist to place the call and that the call is 3337 administratively authorized. Once the outbound call is connected, 3338 the LAC sends an OCCN to the peer indicating the final result of the 3339 call attempt. 3341 7.4.1 OCRQ Sender States 3343 State Event Action New State 3344 ----- ----- ------ --------- 3345 idle Local open Initiate local wait-control-conn 3346 request control-conn-open 3348 idle Receive OCCN, Clean up idle 3349 OCRP 3351 wait-control- control-conn-open Send OCRQ wait-reply 3352 conn 3354 wait-reply Receive OCRP, none wait-connect 3355 acceptable 3357 wait-reply Receive OCRP, Send CDN, idle 3358 not acceptable clean up 3360 wait-reply Receive OCCN Send CDN, idle 3361 clean up 3363 wait-reply Receive OCRQ, Process as idle 3364 lose tie breaker OCRQ Recipient 3365 (Section 7.4.2) 3367 wait-reply Receive OCRQ, Send CDN wait-reply 3368 win tie breaker for losing 3369 session 3371 wait-connect Receive OCCN none established 3373 wait-connect Receive OCRQ, Send CDN, idle 3374 OCRP clean up 3376 idle, Receive CDN Clean up idle 3377 wait-reply, 3378 wait-connect, 3379 established 3381 established Receive OCRQ, Send CDN, idle 3382 OCRP, OCCN clean up 3384 wait-reply, Local close Send CDN, idle 3385 wait-connect, request clean up 3386 established 3388 wait-control- Local close Clean up idle 3389 conn request 3391 The states associated with the OCRQ sender are as follows: 3393 idle, wait-control-conn 3394 When an outgoing call request is initiated, a control connection 3395 is created as described above, if not already present. Once the 3396 control connection is established, an OCRQ is sent to the LAC, and 3397 the session moves into the wait-reply state. 3399 wait-reply 3400 If a CDN is received, the session is cleaned up and returns to 3401 idle state. If an OCRP is received, the call is in progress, and 3402 the session moves to the wait-connect state. 3404 wait-connect 3405 If a CDN is received, the session is cleaned up and returns to 3406 idle state. If an OCCN is received, the call has succeeded, and 3407 the session may now exchange data. 3409 established 3410 If a CDN is received, the session is cleaned up and returns to 3411 idle state. Alternatively, if the LCCE chooses to terminate the 3412 session, it sends a CDN to the LAC, cleans up the session, and 3413 moves the session to idle state. 3415 7.4.2 OCRQ Recipient (LAC) States 3417 State Event Action New State 3418 ----- ----- ------ --------- 3419 idle Receive OCRQ, Send OCRP, wait-cs-answer 3420 acceptable Place call 3422 idle Receive OCRQ, Send CDN, idle 3423 not acceptable clean up 3425 idle Receive OCRP Send CDN, idle 3426 clean up 3428 idle Receive OCCN, Clean up idle 3429 CDN 3431 wait-cs-answer Call placement Send OCCN established 3432 successful 3434 wait-cs-answer Call placement Send CDN, idle 3435 failed clean up 3437 wait-cs-answer Receive OCRQ, Send CDN, idle 3438 OCRP, OCCN clean up 3440 established Receive OCRQ, Send CDN, idle 3441 OCRP, OCCN clean up 3443 wait-cs-answer, Receive CDN Clean up idle 3444 established 3446 wait-cs-answer, Local close Send CDN, idle 3447 established request clean up 3449 The states associated with the LAC for outgoing calls are as follows: 3451 idle 3452 If the OCRQ is received in error, respond with a CDN. Otherwise, 3453 place the call, send an OCRP, and move to the wait-cs-answer 3454 state. 3456 wait-cs-answer 3457 If the call is not completed or a timer expires while waiting for 3458 the call to complete, send a CDN with the appropriate error 3459 condition set, and go to idle state. If a circuit-switched 3460 connection is established, send an OCCN indicating success, and go 3461 to established state. 3463 established 3464 If the LAC receives a CDN from the peer, the call MUST be released 3465 via appropriate mechanisms, and the session cleaned up. If the 3466 call is disconnected because the circuit transitions to a 3467 "disconnected" or "down" state, the LAC MUST send a CDN to the 3468 peer and return to idle state. 3470 7.5 Termination of a Control Connection 3472 The termination of a control connection consists of either peer 3473 issuing a StopCCN. The sender of this message SHOULD wait a full 3474 control message retransmission cycle (e.g. 1 + 2 + 4 + 8 ... seconds) 3475 for the acknowledgment of this message before releasing the control 3476 information associated with the control connection. The recipient of 3477 this message should send an acknowledgment of the message to the 3478 peer, then release the associated control information. 3480 When to release a control connection is an implementation issue and 3481 is not specified in this document. A particular implementation may 3482 use whatever policy is appropriate for determining when to release a 3483 control connection. Some implementations may leave a control 3484 connection open for a period of time or perhaps indefinitely after 3485 the last session for that control connection is cleared. Others may 3486 choose to disconnect the control connection immediately after the 3487 last call on the control connection disconnects. 3489 8. Security Considerations 3491 This section addresses some of the security issues that L2TP 3492 encounters in its operation. 3494 8.1 Control Connection Endpoint and Message Security 3496 The LCCEs may configure a shared secret (password) in order to 3497 perform a mutual authentication of one another, and construct an 3498 authentication and integrity check of all arriving Control Messages. 3499 This mechanism is built-in to L2TPv3, and is described in section 4.3 3500 and in the definition of the Message Digest and Nonce AVPs in section 3501 5.4.3. 3503 This mechanism provides strong mutual peer authentication, and 3504 authentication and integrity checking for individual Control 3505 Messages. 3507 8.2 Data Channel Security 3509 As described in section 4.1, the Assigned Cookie sent with each data 3510 packet MUST be selected in an unpredictable manner (with the added 3511 restriction that two same Cookie values not be selected within a 3512 short period of time for a given Session ID). 3514 A 64-bit Cookie provides effective protection against a blind packet 3515 insertion attack on a given PE. This is useful as a security feature 3516 only within networks where sniffing and correlating packets between 3517 L2TP nodes is considered impossible, though inserting IP packets 3518 destined to an LCCE may be considered possible (and perhaps trivial 3519 by an individual armed with the proper hacking tools). In such cases, 3520 the Cookie provides an effective barrier against packet insertion 3521 into a VPN by enforcing that a given Session ID match the random 64 3522 bit Cookie. A 32 bit Cookie is vulnerable to brute force guessing at 3523 high packet rates, and as such should not be considered an effective 3524 barrier to insertion attacks (it still provides an additional 3525 integrity check for the Session ID, as described in section 4.1). 3527 The L2TPv3 Cookie MUST NOT be regarded as a substitute for packet- 3528 level security such as that of IPsec when operating over an open or 3529 untrusted network where packets may be sniffed and values correlated 3530 to spoofed packets. L2TPv3 does not attempt to provide data packet 3531 encryption of any kind (without the aid of IPsec). 3533 8.3 End-to-End Security 3535 Protecting the L2TP packet stream with IPsec does, in turn, also 3536 protect the data within the tunneled session packets while 3537 transported from one LCCE to the other. Such protection MUST NOT be 3538 considered a substitution for end-to-end security between 3539 communicating hosts or applications. 3541 8.4 L2TP and IPsec 3543 When running over IP, IPsec [RFC2401] provides packet-level security 3544 via ESP [RFC3193]. All L2TP control and data packets for a 3545 particular control connection appear as homogeneous UDP or IP data 3546 packets to the IPsec system. 3548 In addition to IP transport security, IPsec defines a mode of 3549 operation that allows tunneling of IP packets. The packet-level 3550 encryption and authentication provided by IPsec tunnel mode and that 3551 provided by L2TP secured with IPsec provide an equivalent level of 3552 security for these requirements. 3554 IPsec also defines access control features that are required of a 3555 compliant IPsec implementation. These features allow filtering of 3556 packets based upon network and transport layer characteristics such 3557 as IP address, ports, etc. In the L2TP tunneling model, analogous 3558 filtering is logically performed at the network layer above L2TP. 3559 These network layer access control features may be handled at an LCCE 3560 via vendor-specific authorization features based upon the 3561 authenticated user, or at the network layer itself by using IPsec 3562 transport mode end-to-end between the communicating hosts. The 3563 requirements for access control mechanisms are not a part of the L2TP 3564 specification and as such are outside the scope of this document. 3566 8.5 Impact of L2TPv3 Features on RFC 3193 3568 [RFC3193] defines the recommended method for securing L2TPv2. L2TPv3 3569 possesses identical characteristics to IPsec as L2TPv2 when running 3570 on UDP/IP. When operating over IP directly, the principles defined 3571 in [RFC3193] still apply, though references to UDP port selection (in 3572 particular Section 4 "IPsec Filtering details when protecting L2TP") 3573 become far simpler as there are two less variable parameters (source 3574 and destination UDP ports) to be concerned with when applying 3575 filters. Specific details for operating L2TPv3 with IPsec will be 3576 specified in an update to [RFC3193]. 3578 9. Internationalization Considerations 3580 The Host Name and Vendor Name AVPs are not internationalized. The 3581 Vendor Name AVP, although intended to be human-readable, would seem 3582 to fit in the category of "globally visible names" [RFC2277] and so 3583 is represented in US-ASCII. 3585 The Preferred Language AVP is not mandatory. If an LCCE does not 3586 signify a language preference by the inclusion of this AVP in the 3587 SCCRQ or SCCRP, the Preferred Language AVP is unrecognized, or the 3588 requested language is not supported by the peer LCCE, the default 3589 language [RFC2277] MUST be used for all internationalized strings 3590 sent by the peer. 3592 10. IANA Considerations 3594 This document defines a number of "magic" numbers to be maintained by 3595 the IANA. This section explains the criteria to be used by the IANA 3596 to assign additional numbers in each of these lists. The following 3597 subsections describe the assignment policy for the namespaces defined 3598 elsewhere in this document. 3600 10.1 Control Message Attribute Value Pairs (AVPs) 3602 This number space is managed by IANA as per [RFC3438]. 3604 New AVPs requiring assignment in this document are defined in the 3605 "AVP Summary," Section 5.4, with the encoding "AVP-TBA-x," where "x" 3606 is 1, 2, 3... 3608 A summary of the new AVPs follows: 3610 AVP-TBA-1 Message Digest 3611 AVP-TBA-2 Router ID, 3612 AVP-TBA-3 Assigned Control Connection ID 3613 AVP-TBA-4 Pseudowire Capabilities List 3614 AVP-TBA-5 Local Session ID 3615 AVP-TBA-6 Remote Session ID 3616 AVP-TBA-7 Assigned Cookie 3617 AVP-TBA-8 Remote End ID 3618 AVP-TBA-9 Application Code 3619 AVP-TBA-10 Pseudowire Type 3620 AVP-TBA-11 L2-Specific Sublayer 3621 AVP-TBA-12 Data Sequencing 3622 AVP-TBA-13 Circuit Status 3623 AVP-TBA-14 Preferred Language 3624 AVP-TBA-15 Control Message Authentication Nonce 3626 10.2 Message Type AVP Values 3628 This number space is managed by IANA as per [RFC3438]. There is one 3629 new message type, defined in section 3.1, necessary to be allocated 3630 for this specification: 3631 TBA-M1 (ACK) Explicit Acknowledgement 3633 10.3 Result Code AVP Values 3635 This number space is managed by IANA as per [RFC3438]. 3637 New Result Code values for the CDN message are defined in section 3638 5.4. Following is a summary: 3640 RC-TBA-1 - Session not established due to losing tie breaker. 3641 RC-TBA-2 - Session not established due to unsupported PW type. 3642 RC-TBA-3 - Session not established, sequencing required without valid 3643 L2-Specific Sublayer. 3645 There are a few cases in Section 5 where these values are referred to 3646 directly within the document text with the RC-TBA-x format. The 3647 assigned values should be inserted within the text for these cases. 3649 10.3.2 Error Code Field Values 3651 This number space is managed by IANA as per [RFC3438]. 3653 10.4 AVP Header Bits 3655 There are four remaining reserved bits in the AVP header. Additional 3656 bits should only be assigned via a Standards Action [RFC2434]. 3658 10.5 L2TP Control Message Header Bits 3660 There are nine remaining reserved bits in the control message header. 3661 Additional bits should only be assigned via a Standards Action 3662 [RFC2434]. 3664 Care should be taken before using reserved bits 6 and 7 in the L2TPv3 3665 control message header since these bits have meaning for L2TPv2 data 3666 messages. Using these two bits in L2TPv3 MAY trigger an unforeseen 3667 interoperability problem with L2TPv3 implementations based on L2TPv2. 3668 Therefore, it is recommended that these two bits be utilized last, 3669 after the other reserved bits have been assigned roles. 3671 10.6 Pseudowire Types 3673 The Pseudowire Type (PW Type, Section 5.4) is a two-octet value used 3674 in the Pseudowire Type AVP and Pseudowire Capabilities List AVP 3675 defined in Section 5.4.3. 0 to 32767 are assignable by Expert Review 3676 [RFC2434], 32768 to 65535 by a First Come First Served policy 3677 [RFC2434]. There are no specific pseudowire types assigned within 3678 this document. Each pseudowire-specific document MUST allocate its 3679 own PW types from IANA as necessary. 3681 10.7 Application Code 3683 The Application Code (Section 5.4) is a two-octet value used in the 3684 Application Code AVP. Value 0 is assigned to the base application 3685 defined in this document. Additional Application Codes may be 3686 assigned by IETF Consensus [RFC2434]. 3688 10.8 Circuit Status Bits 3690 The Circuit Status (Section 5.4) field is a 16 bit mask, with the two 3691 high order bits assigned. 3693 Bit 15 - A (Active) bit 3694 Bit 16 - N (New) bit 3696 Additional bits may be assigned by IETF Consensus [RFC2434]. 3698 10.9 Default L2-Specific Sublayer bits 3700 The Default L2 Specific Sublayer defined in Section 4.6 contains 8 3701 bits in the low-order portion of the header, one of which has been 3702 assigned and 7 remain. 3704 Bit 1 - S (Sequence) bit 3706 Additional values may be assigned by IETF Consensus [RFC2434]. 3708 10.10 L2-Specific Sublayer Type 3710 The L2-Specific Sublayer Type is a 2 octet unsigned integer of which 3711 two values have been assigned. 3713 0 - No L2-Specific Sublayer 3714 1 - Default L2-Specific Sublayer present 3716 Additional values may be assigned by Expert Review [RFC2434]. 3718 10.11 Data Sequencing Level 3720 The Data Sequencing Level is a 2 octet unsigned integer of which 3721 three values have been assigned. 3723 0 - No incoming data packets require sequencing. 3724 1 - Only non-IP data packets require sequencing. 3725 2 - All incoming data packets require sequencing. 3727 Additional values may be assigned by Expert Review [RFC2434]. 3729 13. Acknowledgments 3731 Many of the protocol constructs were originally defined in, and the 3732 text of this document began with, RFC 2661, "L2TPv2". RFC 2661 3733 authors are W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn and 3734 B. Palter. 3736 The basic concept for L2TP and many of its protocol constructs were 3737 adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these 3738 drafts are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, 3739 W. Verthein, J. Taarud, W. Little, and G. Zorn. 3741 Danny Mcpherson and Suhail Nanji published the first "L2TP Service 3742 Type" draft which defined the use of L2TP for tunneling of various L2 3743 payload types (initially, Ethernet and Frame Relay). 3745 The team for splitting RFC 2661 into this base document and the 3746 companion PPP document consisted of Ignacio Goyret, Jed Lau, Bill 3747 Palter, Mark Townsley, and Madhvi Verma. Skip Booth also provided 3748 very helpful review and comment. 3750 Some constructs of L2TPv3 were based in part on UTI (Universal 3751 Transport Interface), which was originally conceived by Peter 3752 Lothberg and Tony Bates. 3754 Stewart Bryant and Simon Barber provided valuable input for the 3755 L2TPv3 over IP header. 3757 Juha Heinanen provided helpful review, and input for the Application 3758 ID AVP. 3760 Jan Vilhuber, Scott Fluhrer, David McGrew, Scott Wainner, and Skip 3761 Booth contributed to the Control Message and Authentication Mechanism 3762 as well as general discussions of security. 3764 James Carlson, Thomas Narten and Maria Dos Santos provided very 3765 helpful review of the final text. 3767 A number of people provided valuable input and effort for RFC2661, on 3768 which this document was based: 3770 John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, 3771 Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and 3772 review at the 43rd IETF in Orlando, FL, which led to improvement of 3773 the overall readability and clarity of RFC 2661. 3775 Thomas Narten provided a great deal of critical review and 3776 formatting. He wrote the first version of the IANA Considerations 3777 section. 3779 Dory Leifer made valuable refinements to the protocol definition of 3780 L2TP and contributed to the editing of early drafts leading to RFC 3781 2661. 3783 Steve Cobb and Evan Caves redesigned the state machine tables. 3785 Barney Wolff provided a great deal of design input on the endpoint 3786 authentication mechanism. 3788 11. References 3790 11.1 Normative References 3792 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 3793 RFC 1958, June 1996. 3795 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 3796 Protocol (CHAP)", RFC 1994, August 1996. 3798 [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, 3799 January 1997. 3801 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3802 Requirement Levels", BCP 14, RFC 2119, March 1997. 3804 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 3805 Languages", BCP 18, RFC 2277, January 1998. 3807 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3808 IANA Considerations section in RFCs", BCP 26, RFC 2434, 3809 October 1998. 3811 [RFC2661] Townsley, W., et al., "Layer Two Tunneling Layer Two Tunneling 3812 Protocol (L2TP)", RFC 2661, August 1999. 3814 [RFC2865] Rigney, C., Rubens, A., Simpson, W., and Willens, S., 3815 "Remote Authentication Dial In User Service (RADIUS)", 3816 RFC 2865, June 2000. 3818 [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", 3819 RFC 3066, January 2001. 3821 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and Booth, S., 3822 "Securing L2TP using IPsec", RFC 3193, November 2001. 3824 11.2 Informative References 3826 [KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network 3827 Security: Private Communications in a Public World", 3828 Prentice Hall, March 1995, ISBN 0-13-061466-1. 3830 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 3831 STD 13, RFC 1034, November 1987. 3833 [RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, 3834 04/16/1992 3836 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 3837 RFC 1661, July 1994. 3839 [RFC1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, 3840 RFC 1700, October 1994. See also: 3841 http://www.iana.org/numbers.html. 3843 [RFC1750] D. Eastlake III, S. Crocker, J. Schiller, "Randomness 3844 Recommendations for Security", RFC 1750, December 1994 3846 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for 3847 Message Authentication", RFC 2104, February 1997 3849 [RFC2138] Rigney, C., Rubens, A., Simpson, W., and Willens, S., 3850 "Remote Authentication Dial In User Service (RADIUS)", 3851 RFC 2138, April 1997. 3853 [RFC2341] Valencia, A., Littlewood, M., and Kolar, T., 3854 "Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341, 3855 May 1998. 3857 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 3858 Internet Protocol", RFC 2401, November 1998. 3860 [RFC2581] Allman, M., Paxson, V., Stevens, W., "TCP Congestion 3861 Control", RFC 2581, April 1999 3863 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., 3864 and Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", 3865 RFC 2637, July 1999. 3867 [RFC2809] Aboba, B., and Zorn, G., "Implementation of L2TP Compulsory 3868 Tunneling via RADIUS", RFC 2809, April 2000. 3870 [RFC3070] Rawat, V., Tio, R., Nanji, S., and Verma, R., 3871 "Layer Two Tunneling Protocol (L2TP) over Frame Relay", 3872 RFC 3070, February 2001. 3874 [RFC3355] Singh, A., Turner, R., Tio, R., Nanji, S., "Layer Two 3875 Tunnelling Protocol (L2TP) Over ATM Adaptation 3876 Layer 5 (AAL5)", RFC 3355, August 2002 3878 [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I: The 3879 Protocols", Addison-Wesley Publishing Company, Inc., 3880 March 1996, ISBN 0-201-63346-9. 3882 12. Editors' Addresses 3884 Jed Lau 3885 cisco Systems 3886 170 W. Tasman Drive 3887 San Jose, CA 95134 3888 jedlau@cisco.com 3890 W. Mark Townsley 3891 cisco Systems 3892 mark@townsley.net 3894 Ignacio Goyret 3895 Lucent Technologies 3896 igoyret@lucent.com 3898 Appendix A: Control Slow Start and Congestion Avoidance 3900 Although each side has indicated the maximum size of its receive 3901 window, it is recommended that a slow start and congestion avoidance 3902 method be used to transmit control packets. The methods described 3903 here are based upon the TCP congestion avoidance algorithm as 3904 described in section 21.6 of TCP/IP Illustrated, Volume I, by W. 3905 Richard Stevens [STEVENS] (this algorithm is also described in 3906 [RFC2581]). 3908 Slow start and congestion avoidance make use of several variables. 3909 The congestion window (CWND) defines the number of packets a sender 3910 may send before waiting for an acknowledgment. The size of CWND 3911 expands and contracts as described below. Note, however, that CWND 3912 is never allowed to exceed the size of the advertised window obtained 3913 from the Receive Window AVP. (In the text below, it is assumed any 3914 increase will be limited by the Receive Window Size.) The variable 3915 SSTHRESH determines when the sender switches from slow start to 3916 congestion avoidance. Slow start is used while CWND is less than 3917 SSHTRESH. 3919 A sender starts out in the slow start phase. CWND is initialized to 3920 one packet, and SSHTRESH is initialized to the advertised window 3921 (obtained from the Receive Window AVP). The sender then transmits 3922 one packet and waits for its acknowledgment (either explicit or 3923 piggybacked). When the acknowledgment is received, the congestion 3924 window is incremented from one to two. During slow start, CWND is 3925 increased by one packet each time an ACK (explicit ACK message or 3926 piggybacked) is received. Increasing CWND by one on each ACK has the 3927 effect of doubling CWND with each round trip, resulting in an 3928 exponential increase. When the value of CWND reaches SSHTRESH, the 3929 slow start phase ends and the congestion avoidance phase begins. 3931 During congestion avoidance, CWND expands more slowly. Specifically, 3932 it increases by 1/CWND for every new ACK received. That is, CWND is 3933 increased by one packet after CWND new ACKs have been received. 3934 Window expansion during the congestion avoidance phase is effectively 3935 linear, with CWND increasing by one packet each round trip. 3937 When congestion occurs (indicated by the triggering of a 3938 retransmission) one-half of the CWND is saved in SSTHRESH, and CWND 3939 is set to one. The sender then reenters the slow start phase. 3941 Appendix B: Control Message Examples 3943 B.1: Lock-Step Control Connection Establishment 3945 In this example, an LCCE establishes a control connection, with the 3946 exchange involving each side alternating in sending messages. This 3947 example shows the final acknowledgment explicitly sent within an ACK 3948 message. An alternative would be to piggyback the acknowledgment 3949 within a message sent as a reply to the ICRQ or OCRQ that will likely 3950 follow from the side that initiated the control connection. 3952 LCCE A LCCE B 3953 ------ ------ 3954 SCCRQ -> 3955 Nr: 0, Ns: 0 3956 <- SCCRP 3957 Nr: 1, Ns: 0 3958 SCCCN -> 3959 Nr: 1, Ns: 1 3960 <- ACK 3961 Nr: 2, Ns: 1 3963 B.2: Lost Packet with Retransmission 3965 An existing control connection has a new session requested by LCCE A. 3966 The ICRP is lost and must be retransmitted by LCCE B. Note that loss 3967 of the ICRP has two effects: It not only keeps the upper level state 3968 machine from progressing, but also keeps LCCE A from seeing a timely 3969 lower level acknowledgment of its ICRQ. 3971 LCCE A LCCE B 3972 ------ ------ 3973 ICRQ -> 3974 Nr: 1, Ns: 2 3975 (packet lost) <- ICRP 3976 Nr: 3, Ns: 1 3978 (pause; LCCE A's timer started first, so fires first) 3980 ICRQ -> 3981 Nr: 1, Ns: 2 3983 (Realizing that it has already seen this packet, 3984 LCCE B discards the packet and sends an ACK message) 3986 <- ACK 3987 Nr: 3, Ns: 2 3989 (LCCE B's retransmit timer fires) 3991 <- ICRP 3992 Nr: 3, Ns: 1 3993 ICCN -> 3994 Nr: 2, Ns: 3 3996 <- ACK 3997 Nr: 4, Ns: 2 3999 Appendix C: Processing Sequence Numbers 4001 The Default L2-Specific Sublayer, defined in Section 4.6, provides a 4002 24-bit field for sequencing of data packets within an L2TP session. 4003 L2TP data packets are never retransmitted, so this sequence is used 4004 only to detect packet order, duplicate packets, or lost packets. 4006 The 24-bit Sequence Number field of the Default L2-Specific Sublayer 4007 contains a packet sequence number for the associated session. Each 4008 sequenced data packet that is sent must contain the sequence number, 4009 incremented by one, of the previous sequenced packet sent on a given 4010 L2TP session. Upon receipt, any packet with a sequence number equal 4011 to or greater than the current expected packet (the last received 4012 in-order packet plus one) should be considered "new" and accepted. 4013 All other packets are considered "old" or "duplicate" and discarded. 4014 Note that the 24-bit sequence number space includes zero as a valid 4015 sequence number (as such, it may be implemented with a masked 32-bit 4016 counter if desired). All new sessions MUST begin sending sequence 4017 numbers at zero. 4019 Larger or smaller sequence number fields are possible with L2TP if an 4020 alternative format to the Default L2-Specific Sublayer defined in 4021 this document is used. While 24 bits may be adequate in a number of 4022 circumstances, a larger sequence number space will be less 4023 susceptible to sequence number wrapping problems for very high 4024 session data rates across long dropout periods. The sequence number 4025 processing recommendations below should hold for any size sequence 4026 number field. 4028 When detecting whether a packet sequence number is "greater" or 4029 "less" than a given sequence number value, wrapping of the sequence 4030 number must be considered. This is typically accomplished by keeping 4031 a window of sequence numbers beyond the current expected sequence 4032 number for determination of whether a packet is "new" or not. The 4033 window may be sized based on the link speed and sequence number space 4034 and SHOULD be configurable with a default equal to one half the size 4035 of the available number space (e.g. 2^(n-1), where n is the number of 4036 bits available in the sequence number). 4038 Upon receipt, packets which exactly match the expected sequence 4039 number are processed immediately and the next expected sequence 4040 number incremented. Packets that fall within the window for new 4041 packets may either be processed immediately and the next expected 4042 sequence number updated to one plus that received in the new packet, 4043 or held for a very short period of time in hopes of receiving the 4044 missing packet(s). This 'very short period' should be configurable, 4045 with a default corresponding to a time lapse which is at least an 4046 order of magnitude less than the retransmission timeout periods of 4047 higher layer protocols such as TCP. 4049 For typical transient packet mis-orderings, dropping out-of-order 4050 packets alone should suffice and generally requires far less 4051 resources than actively reordering packets within L2TP. An exception 4052 is a case where a pair of packet fragments are persistently 4053 retransmitted and sent out-of-order. For example, if an IP packet has 4054 been fragmented into a very small packet followed by a very large 4055 packet before being tunneled by L2TP, it is possible (though 4056 admittedly wrong) that the two resulting L2TP packets may be 4057 consistently mis-ordered by the PSN in transit between L2TP nodes. If 4058 sequence numbers were being enforced at the receiving node without 4059 any buffering of out-of-order packets, then the fragmented IP packet 4060 may never reach its destination. It may be worth noting here that 4061 this condition is true for any tunneling mechanism of IP packets 4062 which include sequence number checking on receipt (i.e. GRE 4063 [RFC2890]). 4065 Utilization of a Data Sequencing Level (see Section 5.4.3) of 1 (only 4066 non-IP data packets require sequencing) allows IP data packets being 4067 tunneled by L2TP to not utilize sequence numbers, while utilizing 4068 sequence numbers and enforcing packet order for any remaining non-IP 4069 data packets. Depending on the requirements of the link-layer being 4070 tunneled, and the network data traversing the data-link, this is 4071 sufficient in many cases to enforce packet order on frames which 4072 require it (such as end-to-end data-link control messages), while not 4073 on IP packets which are known to be resilient to packet reordering. 4075 If a large number of packets (e.g. more than one new packet window) 4076 are dropped due to an extended outage, or loss of sequence number 4077 state on one side of the connection (perhaps as part of a forwarding 4078 plane reset or failover to a standby node), it is possible that a 4079 large number of packets will be sent in-order, but be wrongly 4080 detected by the peer as out-of-order. This can be generally 4081 characterized for a window size, w, sequence number space, s, and 4082 number of packets lost in transit between L2TP endpoints, p, as 4083 follows: 4085 If s > p > w, then an additional (s - p) packets that were otherwise 4086 received in-order, will be incorrectly classified as out-of-order and 4087 dropped. Thus, for a sequence number space, s = 128, window size, w = 4088 64, and number of lost packets, p = 70; 128 - 70 = 58 additional 4089 packets would be dropped after the outage until the sequence number 4090 wrapped back to the current expected next sequence number. 4092 To mitigate this additional packet loss, one MUST inspect the 4093 sequence numbers of packets dropped due to being classified as "old" 4094 and reset the expected sequence number accordingly. This may be 4095 accomplished by counting the number of "old" packets dropped that 4096 were in sequence among themselves and upon reaching a threshold, 4097 resetting the next expected sequence number to that seen in the 4098 arriving data packets. Packet timestamps may also be used as an 4099 indicator to reset the expected sequence number by detecting a period 4100 of time over which "old" packets have been received in-sequence. The 4101 ideal thresholds will vary depending on link speed, sequence number 4102 space, and link tolerance to out-of-order packets, and MUST be 4103 configurable. 4105 Appendix D: Intellectual Property Notice 4107 The IETF takes no position regarding the validity or scope of any 4108 intellectual property or other rights that might be claimed to 4109 pertain to the implementation or use of the technology described in 4110 this document or the extent to which any license under such rights 4111 might or might not be available; neither does it represent that it 4112 has made any effort to identify any such rights. Information on the 4113 IETF's procedures with respect to rights in standards-track and 4114 standards-related documentation can be found in BCP-11. Copies of 4115 claims of rights made available for publication and any assurances of 4116 licenses to be made available, or the result of an attempt made to 4117 obtain a general license or permission for the use of such 4118 proprietary rights by implementers or users of this specification can 4119 be obtained from the IETF Secretariat. 4121 The IETF invites any interested party to bring to its attention any 4122 copyrights, patents or patent applications, or other proprietary 4123 rights that may cover technology that may be required to practice 4124 this standard. Please address the information to the IETF Executive 4125 Director. 4127 The IETF has been notified of intellectual property rights claimed in 4128 regard to some or all of the specification contained in this 4129 document. For more information consult the online list of claimed 4130 rights. 4132 Appendix E: Full Copyright Statement 4134 Copyright (C) The Internet Society (2002). All Rights Reserved. 4136 This document and translations of it may be copied and furnished to 4137 others, and derivative works that comment on or otherwise explain it 4138 or assist in its implementation may be prepared, copied, published 4139 and distributed, in whole or in part, without restriction of any 4140 kind, provided that the above copyright notice and this paragraph are 4141 included on all such copies and derivative works. However, this 4142 document itself may not be modified in any way, such as by removing 4143 the copyright notice or references to the Internet Society or other 4144 Internet organizations, except as needed for the purpose of 4145 developing Internet standards in which case the procedures for 4146 copyrights defined in the Internet Standards process must be 4147 followed, or as required to translate it into languages other than 4148 English. 4150 The limited permissions granted above are perpetual and will not be 4151 revoked by the Internet Society or its successors or assigns. 4153 This document and the information contained herein is provided on an 4154 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4155 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4156 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4157 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4158 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.