idnits 2.17.1 draft-ietf-l2tpext-l2tp-base-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 310 instances of too long lines in the document, the longest one being 5 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 3117 has weird spacing: '...eptable conn...' == Line 3124 has weird spacing: '...breaker los...' == Line 3129 has weird spacing: '...ol-conn est...' == Line 3139 has weird spacing: '...ol-conn est...' == Line 3209 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 (August 2003) is 7560 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 3656, but not defined == Missing Reference: 'RFC2890' is mentioned on line 4068, but not defined == Unused Reference: 'RFC1994' is defined on line 3800, but no explicit reference was found in the text == Unused Reference: 'RFC2138' is defined on line 3854, 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 (~~), 13 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Lau 3 Internet-Draft M. Townsley 4 Category: Standards Track cisco Systems 5 I. Goyret 6 Lucent Technologies 7 Editors 8 August 2003 10 Layer Two Tunneling Protocol (Version 3) 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document describes "version 3" of the Layer Two Tunneling 40 Protocol (L2TPv3). L2TPv3 defines the base control protocol and 41 encapsulation for tunneling multiple layer 2 connections between two 42 IP connected nodes. Additional documents detail the specifics for 43 each link-type being emulated. 45 Contents 47 Status of this Memo.......................................... 1 49 1. Introduction............................................. 4 50 1.1 Changes from RFC 2661................................ 5 51 1.2 Specification of Requirements........................ 5 52 1.3 Terminology.......................................... 5 54 2. Topology................................................. 9 56 3. Protocol Overview........................................ 10 57 3.1 Control Message Types................................ 11 58 3.2 L2TP Header Formats.................................. 12 59 3.2.1 L2TP Control Message Header..................... 12 60 3.2.2 L2TP Data Message............................... 13 61 3.3 Control Connection Management........................ 14 62 3.3.1 Control Connection Establishment................ 15 63 3.3.2 Control Connection Teardown..................... 15 64 3.4 Session Management................................... 16 65 3.4.1 Session Establishment for an Incoming Call...... 16 66 3.4.2 Session Establishment for an Outgoing Call...... 16 67 3.4.3 Session Teardown................................ 16 69 4. Protocol Operation....................................... 17 70 4.1 L2TP Over Specific Packet-Switched Networks (PSN).... 17 71 4.1.1 L2TPv3 over IP.................................. 18 72 4.1.2 L2TP over UDP................................... 19 73 4.1.3 IP Fragmentation Issues......................... 21 74 4.2 Reliable Delivery of Control Messages................ 21 75 4.3 Control Connection and Control Message Authentication 23 76 4.4 Keepalive (Hello).................................... 24 77 4.5 Forwarding Session Data Frames....................... 25 78 4.6 Default L2-Specific Sublayer......................... 25 79 4.6.1 Sequencing Data Packets......................... 26 80 4.7 L2TPv2/v3 Interoperability and Migration............. 27 81 4.7.1 L2TPv3 over IP.................................. 27 82 4.7.2 L2TPv3 over UDP................................. 27 83 4.7.3 Automatic L2TPv2 Fallback....................... 28 85 5. Control Message Attribute Value Pairs.................... 28 86 5.1 AVP Format........................................... 29 87 5.2 Mandatory AVPs and Setting the M Bit................. 30 88 5.3 Hiding of AVP Attribute Values....................... 31 89 5.4 AVP Summary.......................................... 33 90 5.4.1 General Control Message AVPs.................... 33 91 5.4.2 Result and Error Codes.......................... 38 92 5.4.3 Control Connection Management AVPs.............. 40 93 5.4.4 Session Management AVPs......................... 45 94 5.4.5 Circuit Status AVPs............................. 54 96 6. Control Connection Protocol Specification................ 56 97 6.1 Start-Control-Connection-Request (SCCRQ)............. 56 98 6.2 Start-Control-Connection-Reply (SCCRP)............... 57 99 6.3 Start-Control-Connection-Connected (SCCCN)........... 57 100 6.4 Stop-Control-Connection-Notification (StopCCN)....... 57 101 6.5 Hello (HELLO)........................................ 58 102 6.6 Incoming-Call-Request (ICRQ)......................... 58 103 6.7 Incoming-Call-Reply (ICRP)........................... 59 104 6.8 Incoming-Call-Connected (ICCN)....................... 60 105 6.9 Outgoing-Call-Request (OCRQ)......................... 60 106 6.10 Outgoing-Call-Reply (OCRP).......................... 61 107 6.11 Outgoing-Call-Connected (OCCN)...................... 62 108 6.12 Call-Disconnect-Notify (CDN)........................ 62 109 6.13 WAN-Error-Notify (WEN).............................. 63 110 6.14 Set-Link-Info (SLI)................................. 63 111 6.15 Explicit-Acknowledgement (ACK)...................... 64 113 7. Control Connection State Machines........................ 64 114 7.1 Malformed Control Messages........................... 65 115 7.2 Control Connection States............................ 66 116 7.3 Incoming Calls....................................... 68 117 7.3.1 ICRQ Sender States.............................. 68 118 7.3.2 ICRQ Recipient States........................... 70 119 7.4 Outgoing Calls....................................... 71 120 7.4.1 OCRQ Sender States.............................. 71 121 7.4.2 OCRQ Recipient (LAC) States..................... 73 122 7.5 Termination of a Control Connection.................. 74 124 8. Security Considerations.................................. 74 125 8.1 Control Connection Endpoint and Message Security..... 74 126 8.2 Data Channel Security................................ 75 127 8.3 End-to-End Security.................................. 75 128 8.4 L2TP and IPsec....................................... 75 129 8.5 Impact of L2TPv3 Features on RFC 3193................ 76 131 9. Internationalization Considerations...................... 76 133 10. IANA Considerations..................................... 76 134 10.1 Control Message Attribute Value Pairs (AVPs)........ 77 135 10.2 Message Type AVP Values............................. 77 136 10.3 Result Code AVP Values.............................. 77 137 10.3.2 Error Code Field Values........................ 78 138 10.4 AVP Header Bits..................................... 78 139 10.5 L2TP Control Message Header Bits.................... 78 140 10.6 Pseudowire Types..................................... 78 141 10.7 Application Code..................................... 78 142 10.8 Circuit Status Bits.................................. 78 143 10.9 Default L2-Specific Sublayer bits.................... 79 144 10.10 L2-Specific Sublayer Type........................... 79 145 10.11 Data Sequencing Level............................... 79 147 13. Acknowledgments......................................... 79 149 11. References.............................................. 81 150 11.1 Normative References................................ 81 151 11.2 Informative References.............................. 81 153 12. Editors' Addresses...................................... 83 155 Appendix A: Control Slow Start and Congestion Avoidance...... 83 157 Appendix B: Control Message Examples......................... 84 159 Appendix C: Processing Sequence Numbers...................... 85 161 Appendix D: Intellectual Property Notice..................... 87 163 Appendix E: Full Copyright Statement......................... 88 165 1. Introduction 167 The Layer Two Tunneling Protocol (L2TP) provides a dynamic mechanism 168 for tunneling Layer 2 (L2) "circuits" across a packet-oriented data 169 network (e.g., over IP). L2TP, as originally defined in RFC 2661, is 170 a standard method for tunneling Point to Point Protocol (PPP) 171 [RFC1661] sessions. L2TP has since been adopted for tunneling a 172 number of other L2 protocols. In order to provide greater 173 modularity, this document describes the base L2TP protocol, 174 independent of the L2 payload that is being tunneled. 176 The base L2TP protocol defined in this document consists of (1) the 177 control protocol for dynamic creation, maintenance, and teardown of 178 L2TP sessions, and (2) the L2TP data encapsulation to multiplex and 179 demultiplex L2 data streams between two L2TP nodes across an IP 180 network. Additional documents are expected to be published for each 181 layer 2 data link emulation type (a.k.a. pseudowire-type) supported 182 by L2TP (i.e., PPP, Ethernet, Frame Relay, etc.). These documents 183 will contain any individual details that are outside the scope of 184 this base specification. 186 1.1 Changes from RFC 2661 188 Many of the protocol constructs described in this document are 189 carried over from RFC 2661. Changes include clarifications based on 190 years of interoperability and deployment experience as well as 191 modifications to either improve protocol operation or provide a 192 clearer separation from PPP. The intent of these modifications is to 193 achieve a healthy balance between code reuse, interoperability 194 experience, and a directed evolution of L2TP as it is applied to new 195 tasks. 197 When the designation between L2TPv2 and L2TPv3 is necessary, L2TP as 198 defined in RFC 2661 will be referred to as "L2TPv2", corresponding to 199 the value in the Version field of an L2TP header. (Layer 2 200 Forwarding, L2F, [RFC2341] was defined as "version 1".) At times, 201 L2TP as defined in this document will be referred to as "L2TPv3". 202 Otherwise, the acronym "L2TP" will refer to L2TPv3 or L2TP in 203 general. 205 Notable differences between L2TPv2 and L2TPv3 include: 207 Separation of all PPP-related AVPs, references, etc., including a 208 portion of the L2TP data header that was specific to the needs of 209 PPP. The PPP-specific constructs are described in a companion 210 document. 212 Transition from a 16-bit Session ID and Tunnel ID to a 32-bit 213 Session ID and Control Connection ID, respectively. 215 Extension of the Tunnel Authentication mechanism to cover the 216 entire control message rather than just a portion of certain 217 messages. 219 Details of these changes and a recommendation for transitioning to 220 L2TPv3 may be found in Section 4.7. 222 1.2 Specification of Requirements 224 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 225 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 226 document are to be interpreted as described in [RFC2119]. 228 1.3 Terminology 230 Attribute Value Pair (AVP) 232 The variable-length concatenation of a unique Attribute 233 (represented by an integer), a length field, and a Value 234 containing the actual value identified by the attribute. Zero or 235 more AVPs make up the body of control messages, which are used in 236 the establishment, maintenance, and teardown of control 237 connections. This basic construct is sometimes referred to as a 238 Type-Length-Value (TLV) in some specifications. (See also: 239 Control Connection, Control Message.) 241 Call (Circuit Up) 243 The action of transitioning a circuit on an L2TP Access 244 Concentrator (LAC) to an "up" or "active" state. A call may be 245 dynamically established through signaling properties (e.g., an 246 incoming or outgoing call through the Public Switched Telephone 247 Network (PSTN)) or statically configured (e.g., provisioning a 248 Virtual Circuit on an interface). A call is defined by its 249 properties (e.g., type of call, called number, etc.) and its data 250 traffic. (See also: Circuit, Session, Incoming Call, Outgoing 251 Call, Outgoing Call Request.) 253 Circuit 255 A general term identifying any one of a wide range of L2 256 connections. A circuit may be virtual in nature (e.g., an ATM 257 PVC, an ethernet VLAN, or an L2TP session), or it may have direct 258 correlation to a physical layer (e.g., an RS-232 serial line). 259 Circuits may be statically configured with a relatively long-lived 260 uptime, or dynamically established with signaling to govern the 261 establishment, maintenance, and teardown of the circuit. For the 262 purposes of this document, a statically configured circuit is 263 considered to be essentially the same as a very simple, long- 264 lived, dynamic circuit. (See also: Call, Remote System.) 266 Client 268 (See Remote System.) 270 Control Connection 272 An L2TP control connection is a reliable control channel that is 273 used to establish, maintain, and release individual L2TP sessions 274 as well as the control connection itself. (See also: Control 275 Message, Data Channel.) 277 Control Message 279 An L2TP message used by the control connection. (See also: 280 Control Connection.) 282 Data Message 284 Message used by the data channel. (a.k.a. Data Packet, See also: 285 Data Channel.) 287 Data Channel 289 The channel for L2TP-encapsulated data traffic that passes between 290 two LCCEs over a Packet Switched Network (i.e. IP). (See also: 291 Control Connection, Data Message.) 293 Incoming Call 295 The action of receiving a call (circuit up event) on an LAC. The 296 call may have been placed by a remote system (e.g., a phone call 297 over a PSTN), or it may have been triggered by a local event 298 (e.g., interesting traffic routed to a virtual interface). An 299 incoming call that needs to be tunneled (as determined by the LAC) 300 results in the generation of an L2TP ICRQ message. (See also: 301 Call, Outgoing Call, Outgoing Call Request.) 303 L2TP Access Concentrator (LAC) 305 If an L2TP Control Connection Endpoint (LCCE) is being used to 306 cross-connect an L2TP session directly to a data link, we refer to 307 it as an L2TP Access Concentrator (LAC). An LCCE may act as both 308 an L2TP Network Server (LNS) for some sessions and an LAC for 309 others, so these terms must only be used within the context of a 310 given set of sessions unless the LCCE is in fact single purpose 311 for a given topology. (See also: LCCE, LNS.) 313 L2TP Control Connection Endpoint (LCCE) 315 An L2TP node which exists at either end of an L2TP control 316 connection. May also be referred to as an LAC or LNS, depending on 317 whether tunneled frames are processed at the data link (LAC) or 318 network layer (LNS). (See also: LAC, LNS.) 320 L2TP Network Server (LNS) 322 If a given L2TP session is terminated at the L2TP node and the 323 encapsulated network layer (L3) packet processed on a virtual 324 interface, we refer to this L2TP node as an L2TP Network Server 325 (LNS). A given LCCE may act as both an LNS for some sessions and 326 an LAC for others, so these terms must only be used within the 327 context of a given set of sessions unless the LCCE is in fact 328 single purpose for a given topology. (See also: LCCE, LAC.) 330 Outgoing Call 332 The action of placing a call by an LAC, typically in response to 333 policy directed by the peer in an Outgoing Call Request message. 334 (See also: Call, Incoming Call, Outgoing Call Request.) 336 Outgoing Call Request 338 A request sent to an LAC to place an outgoing call. The request 339 contains specific information not known a priori by the LAC (i.e., 340 a number to dial). (See also: Call, Incoming Call, Outgoing 341 Call.) 343 Packet-Switched Network (PSN) 345 A network that uses packet-switching technology for data delivery. 346 For L2TPv3, this layer is principally IP. Other examples include 347 MPLS, Frame Relay, and ATM. 349 Peer 351 When used in context with L2TP, Peer refers to the far end of an 352 L2TP control connection (i.e., the remote LCCE). An LAC's peer 353 may be either an LNS or another LAC. Similarly, an LNS's peer may 354 be either an LAC or another LNS. (See also: LAC, LCCE, LNS.) 356 Pseudowire (PW) 358 An emulated circuit as it traverses a PSN. There is one 359 Pseudowire per L2TP Session. (See also: Packet-Switched Network, 360 Session.) 362 Pseudowire Type 364 The payload type being carried within an L2TP session. Examples 365 include PPP, Ethernet, and Frame Relay. (See also: Session.) 367 Remote System 369 An end-system or router connected by a circuit to an LAC. 371 Session 373 An L2TP session is the entity which is created between two LCCEs 374 in order to exchange parameters for and maintain an emulated L2 375 connection. Multiple sessions may be associated with a single 376 Control Connection. 378 Zero-Length Body (ZLB) Message 380 A control message with only an L2TP header. ZLB messages are used 381 only to acknowledge messages on the L2TP reliable control channel. 382 (See also: Control Message.) 384 2. Topology 386 L2TP operates between two L2TP Control Connection Endpoints (LCCEs), 387 tunneling traffic across a packet network. There are three 388 predominant tunneling models in which L2TP operates: LAC-LNS (or vice 389 versa), LAC-LAC, and LNS-LNS. These models are diagrammed below. 390 (Dotted lines designate network connections. Solid lines designate 391 circuit connections.) 393 Figure 2.0: L2TP Reference Models 395 (a) LAC-LNS Reference Model: On one side, the LAC receives traffic 396 from an L2 circuit, which it forwards via L2TP across an IP or other 397 packet-based network. On the other side, an LNS logically terminates 398 the L2 circuit locally and routes network traffic to the home 399 network. The action of session establishment is driven by the LAC 400 (as an incoming call) or the LNS (as an outgoing call). 402 +-----+ L2 +-----+ +-----+ 403 | |------| LAC |.........[ IP ].........| LNS |...[home network] 404 +-----+ +-----+ +-----+ 405 remote 406 system 407 |<-- emulated service -->| 408 |<----------- L2 service ------------>| 410 (b) LAC-LAC Reference Model: In this model, both LCCEs are LACs. 411 Each LAC forwards circuit traffic from the remote system to the peer 412 LAC using L2TP, and vice versa. In its simplest form, an LAC acts as 413 a simple cross-connect between a circuit to a remote system and an 414 L2TP session. This model typically involves symmetric establishment; 415 that is, either side of the connection may initiate a session at any 416 time (or simultaneously, in which a tie-breaking mechanism is 417 utilized). 419 +-----+ L2 +-----+ +-----+ L2 +-----+ 420 | |------| LAC |........[ IP ]........| LAC |------| | 421 +-----+ +-----+ +-----+ +-----+ 422 remote remote 423 system system 424 |<- emulated service ->| 425 |<----------------- L2 service ----------------->| 427 (c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs. A 428 user-level, traffic-generated, or signaled event typically drives 429 session establishment from one side of the tunnel. For example, a 430 tunnel generated from a PC by a user, or automatically by customer 431 premises equipment. 433 +-----+ +-----+ 434 [home network]...| LNS |........[ IP ]........| LNS |...[home network] 435 +-----+ +-----+ 436 |<- emulated service ->| 437 |<---- L2 service ---->| 439 Note: In L2TPv2, user-driven tunneling of this type is often referred 440 to as "voluntary tunneling" [RFC2809]. Further, an LNS acting as part 441 of a software package on a host is sometimes referred to as an "LAC 442 Client" [RFC2661]. 444 3. Protocol Overview 446 L2TP utilizes two types of messages, control messages and data 447 messages (sometimes referred to as "control packets" and "data 448 packets", respectively). Control messages are used in the 449 establishment, maintenance, and clearing of control connections and 450 sessions. These messages utilize a reliable control channel within 451 L2TP to guarantee delivery (see Section 4.2 for details). Data 452 messages are used to encapsulate the L2 traffic being carried over 453 the L2TP session. Unlike control messages, data messages are not 454 retransmitted when packet loss occurs. 456 The L2TPv3 control message format defined in this document borrows 457 largely from L2TPv2. These control messages are used in conjunction 458 with the associated protocol state machines that govern the dynamic 459 setup, maintenance, and teardown for L2TP sessions. The data message 460 format for tunneling data packets may be utilized with or without the 461 L2TP control channel, either via manual configuration or other 462 signaling methods to pre-configure or distribute L2TP session 463 information. Utilization of the L2TP data message format with other 464 signaling methods is outside the scope of this document. 466 Figure 3.0: L2TPv3 Structure 468 +-------------------+ +-----------------------+ 469 | Tunneled Frame | | L2TP Control Message | 470 +-------------------+ +-----------------------+ 471 | L2TP Data Header | | L2TP Control Header | 472 +-------------------+ +-----------------------+ 473 | L2TP Data Channel | | L2TP Control Channel | 474 | (unreliable) | | (reliable) | 475 +-------------------+----+-----------------------+ 476 | Packet-Switched Network (IP, FR, MPLS, etc.) | 477 +------------------------------------------------+ 479 Figure 3.0 depicts the relationship of control messages and data 480 messages over the L2TP control and data channels, respectively. Data 481 messages are passed over an unreliable data channel, encapsulated by 482 an L2TP header, and sent over a Packet-Switched Network (PSN) such as 483 IP, UDP, Frame Relay, ATM, MPLS, etc. Control messages are sent over 484 a reliable L2TP control channel, which operates over the same PSN. 486 The necessary setup for tunneling a session with L2TP consists of two 487 steps: (1) Establishing the control connection, and (2) establishing 488 a session as triggered by an incoming call or outgoing call. An L2TP 489 session MUST be established before L2TP can begin to forward session 490 frames. Multiple sessions may be bound to a single control 491 connection, and multiple control connections may exist between the 492 same two LCCEs. 494 3.1 Control Message Types 496 The Message Type AVP (see Section 5.4.1) defines the specific type of 497 control message being sent. 499 This document defines the following control message types (see 500 Sections 6.1 through 6.13 for details on the construction and use of 501 each message): 503 Control Connection Management 505 0 (reserved) 506 1 (SCCRQ) Start-Control-Connection-Request 507 2 (SCCRP) Start-Control-Connection-Reply 508 3 (SCCCN) Start-Control-Connection-Connected 509 4 (StopCCN) Stop-Control-Connection-Notification 510 5 (reserved) 511 6 (HELLO) Hello 512 TBA-M1 (ACK) Explicit Acknowledgement 514 Call Management 516 7 (OCRQ) Outgoing-Call-Request 517 8 (OCRP) Outgoing-Call-Reply 518 9 (OCCN) Outgoing-Call-Connected 519 10 (ICRQ) Incoming-Call-Request 520 11 (ICRP) Incoming-Call-Reply 521 12 (ICCN) Incoming-Call-Connected 522 13 (reserved) 523 14 (CDN) Call-Disconnect-Notify 525 Error Reporting 527 15 (WEN) WAN-Error-Notify 529 Link Status Change Reporting 531 16 (SLI) Set-Link-Info 533 3.2 L2TP Header Formats 535 This section defines header formats for L2TP control messages and 536 L2TP data messages. All values are placed into their respective 537 fields and sent in network order (high-order octets first). 539 3.2.1 L2TP Control Message Header 541 The L2TP control message header provides information for the reliable 542 transport of messages that govern the establishment, maintenance, and 543 teardown of L2TP sessions. By default, control messages are sent 544 over the underlying media in-band with L2TP data messages. 546 The L2TP control message header is formatted as follows: 548 Figure 3.2.1: L2TP Control Message Header 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 |T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Control Connection ID | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Ns | Nr | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 The T bit MUST be set to 1, indicating that this is a control 561 message. 563 The L and S bits MUST be set to 1, indicating that the Length field 564 and sequence numbers are present. 566 The x bits are reserved for future extensions. All reserved bits 567 MUST be set to 0 on outgoing messages and ignored on incoming 568 messages. 570 The Ver field indicates the version of the L2TP control message 571 header described in this document. On sending, this field MUST be 572 set to 3 for all messages (unless operating in an environment which 573 includes L2TPv2 [RFC2661] and/or L2F [RFC2341] as well, see Section 574 4.1 for details). 576 The Length field indicates the total length of the message in octets, 577 always calculated from the start of the control message header itself 578 (beginning with the T bit). 580 The Control Connection ID field contains the identifier for the 581 control connection. L2TP control connections are named by 582 identifiers that have local significance only. That is, the same 583 control connection will be given unique Control Connection IDs by 584 each LCCE from within each endpoint's own Control Connection ID 585 number space. As such, the Control Connection ID in each message is 586 that of the intended recipient, not the sender. Non-zero Control 587 Connection IDs are selected and exchanged as Assigned Control 588 Connection ID AVPs during the creation of a control connection. 590 Ns indicates the sequence number for this control message, beginning 591 at zero and incrementing by one (modulo 2**16) for each message sent. 592 See Section 4.2 for more information on using this field. 594 Nr indicates the sequence number expected in the next control message 595 to be received. Thus, Nr is set to the Ns of the last in-order 596 message received plus one (modulo 2**16). See Section 4.2 for more 597 information on using this field. 599 3.2.2 L2TP Data Message 601 In general, an L2TP data message consists of a (1) Session Header, 602 (2) an optional L2-Specific Sublayer, and (3) the Tunnel Payload, as 603 depicted below. 605 Figure 3.2.2: L2TP Data Message Header 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | L2TP Session Header | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | L2-Specific Sublayer | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Tunnel Payload ... 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 The L2TP Session Header is specific to the encapsulating PSN over 616 which the L2TP traffic is delivered. The Session Header MUST provide 617 (1) a method of distinguishing traffic among multiple L2TP data 618 sessions and (2) a method of distinguishing data messages from 619 control messages. 621 Each type of encapsulating PSN MUST define its own session header, 622 clearly identifying the format of the header and parameters necessary 623 to setup the session. Section 4.1 defines two session headers, one 624 for transport over UDP and one for transport over IP. 626 The L2 Specific Sublayer is an intermediary layer between the L2TP 627 session header and the start of the tunneled frame. It contains 628 control fields that are used to facilitate the tunneling of each 629 frame (e.g. sequence numbers or flags). The default L2-Specific 630 Sublayer for L2TPv3 is defined in Section 4.6. 632 The Data Message Header is followed by the Tunnel Payload, including 633 any necessary L2 framing as defined in the payload-specific companion 634 documents. 636 3.3 Control Connection Management 638 The L2TP Control Connection handles dynamic establishment, teardown, 639 and maintenance of the L2TP sessions and of the control connection 640 itself. The reliable delivery of control messages is described in 641 Section 4.2. 643 This section describes typical control connection establishment and 644 teardown exchanges. It is important to note that, in the diagrams 645 that follow, the reliable control message delivery mechanism exists 646 independently of the L2TP state machine. For instance, Explicit 647 Acknowledgement (ACK) messages may be sent after any of the control 648 messages indicated in the exchanges below if an acknowledgment is not 649 piggybacked on a later control message. 651 LCCEs are identified during control connection establishment either 652 by the Host Name AVP, the Router ID AVP, or a combination of the two 653 (see Section 5.4.3). The identity of a peer LCCE is central to 654 selecting proper configuration parameters (i.e. Hello interval, 655 window size, etc.) for a control connection, as well as for 656 determination of how to setup associated sessions within the control 657 connection, password lookup for control connection authentication, 658 control connection level tie-breaking, etc. 660 3.3.1 Control Connection Establishment 662 Establishment of the control connection involves an exchange of AVPs 663 that identifies the peer and its capabilities. 665 A three-message exchange is used to establish the control connection. 666 The following is a typical message exchange: 668 LCCE A LCCE B 669 ------ ------ 670 SCCRQ -> 671 <- SCCRP 672 SCCCN -> 674 3.3.2 Control Connection Teardown 676 Control connection teardown may be initiated by either LCCE and is 677 accomplished by sending a single StopCCN control message. As part of 678 the reliable control message delivery mechanism, the recipient of a 679 StopCCN MUST send an ACK message to acknowledge receipt of the 680 message and maintain enough control connection state to properly 681 accept StopCCN retransmissions over at least a full retransmission 682 cycle (in case the ACK message is lost). The recommended time for a 683 full retransmission cycle is at least 31 seconds (see Section 4.2). 684 The following is an example of a typical control message exchange: 686 LCCE A LCCE B 687 ------ ------ 688 StopCCN -> 689 (Clean up) 691 (Wait) 692 (Clean up) 694 An implementation may shut down an entire control connection and all 695 sessions associated with the control connection by sending the 696 StopCCN. Thus, it is not necessary to clear each session 697 individually when tearing down the whole control connection. 699 3.4 Session Management 701 After successful control connection establishment, individual 702 sessions may be created. Each session corresponds to a single data 703 stream between the two LCCEs. This section describes the typical 704 call establishment and teardown exchanges. 706 3.4.1 Session Establishment for an Incoming Call 708 A three-message exchange is used to establish the session. The 709 following is a typical sequence of events: 711 LCCE A LCCE B 712 ------ ------ 713 (Call 714 Detected) 716 ICRQ -> 717 <- ICRP 718 (Call 719 Accepted) 721 ICCN -> 723 3.4.2 Session Establishment for an Outgoing Call 725 A three-message exchange is used to set up the session. The 726 following is a typical sequence of events: 728 LCCE A LCCE B 729 ------ ------ 730 <- OCRQ 731 OCRP -> 733 (Perform 734 Call 735 Operation) 737 OCCN -> 739 (Call Operation 740 Completed 741 Successfully) 743 3.4.3 Session Teardown 745 Session teardown may be initiated by either the LAC or LNS and is 746 accomplished by sending a CDN control message. After the last 747 session is cleared, the control connection MAY be torn down as well 748 (and typically is). The following is an example of a typical control 749 message exchange: 751 LCCE A LCCE B 752 ------ ------ 753 CDN -> 754 (Clean up) 756 (Clean up) 758 4. Protocol Operation 760 4.1 L2TP Over Specific Packet-Switched Networks (PSN) 762 If necessary, L2TP may operate over a variety of Packet Switched 763 Networks. There are two modes described for operation over IPv4, L2TP 764 over IP (Section 4.1.1) and L2TP over UDP (Section 4.1.2). L2TPv3 765 implementations MUST support L2TP over IP and SHOULD support L2TP 766 over UDP for better NAT and FW traversal, and easier migration from 767 L2TPv2. 769 L2TP over other PSNs may be defined, but the specifics are outside 770 the scope of this document. Examples of L2TPv2 over other PSNs 771 include [RFC3070] and [RFC3355]. 773 The following field definitions are defined for use in all L2TP 774 Session Header encapsulations. 776 Session ID 778 A 32-bit field containing a non-zero identifier for a session. 779 L2TP sessions are named by identifiers that have local 780 significance only. That is, the same logical session will be 781 given different Session IDs by each end of the control connection 782 for the life of the session. When the L2TP control connection is 783 used for session establishment, Session IDs are selected and 784 exchanged as Local Session ID AVPs during the creation of a 785 session. 787 Cookie 789 The optional Cookie field contains a variable length (maximum 64 790 bits), value used to check the association of a received data 791 message with the session identified by the Session ID. The Cookie 792 MUST be set to the configured or signaled random value for this 793 session utilizing all bits in the field. The Cookie provides an 794 additional level of guarantee that a data message has been 795 directed to the proper session by the Session ID. A well-chosen 796 Cookie may prevent inadvertent misdirection of stray packets with 797 recently reused Session IDs, Session IDs subject to packet 798 corruption, etc. The Cookie may also provide protection against 799 some specific malicious packet insertion attacks, as described in 800 section 8.2. 802 When the L2TP control connection is used for session 803 establishment, random Cookie values are selected and exchanged as 804 Assigned Cookie AVPs during session creation. 806 4.1.1 L2TPv3 over IP 808 L2TPv3 over IP utilizes the IANA assigned IP protocol ID 115. 810 4.1.1.1 L2TPv3 Session Header Over IP 812 Unlike L2TP over UDP, the L2TPv3 session header over IP is free of 813 any restrictions imposed by coexistence with L2TPv2 and L2F. As 814 such, the header format has been redesigned to optimize packet 815 processing. The following session header format is utilized when 816 operating L2TPv3 over IP: 818 Figure 4.1.1.1: L2TPv3 Session Header Over IP 820 0 1 2 3 821 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 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Session ID | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Cookie (optional, maximum 64 bits)... 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 The Session ID and Cookie fields are as defined in Section 4.1. The 831 Session ID of zero is reserved for use by L2TP control messages (see 832 Section 4.1.1.2). 834 4.1.1.2 L2TP Control and Data Traffic over IP 836 Unlike L2TP over UDP which uses the common T bit to distinguish 837 between L2TP control and data packets, L2TP over IP uses the reserved 838 Session ID of zero (0) when sending control messages. It is presumed 839 that checking for the zero Session ID is more efficient -- both in 840 header size for data packets and in processing speed for 841 distinguishing between control and data messages -- than checking for 842 the presence of a given single bit. 844 The entire control message header over IP, including the zero session 845 ID, appears as follows: 847 Figure 4.1.1.2: L2TPv3 Control Message Header Over IP 849 0 1 2 3 850 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 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | (32 bits of zeros) | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 |T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Control Connection ID | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Ns | Nr | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 Named fields are as defined in Section 3.2.1. Note that the Length 862 field is still calculated from the beginning of the control message 863 header, beginning with the T bit. It does NOT include the "(32 bits 864 of zeros)" depicted above. 866 When operating directly over IP, L2TP packets lose the ability to 867 take advantage of the UDP checksum as a simple packet integrity 868 check. This is of particular concern for L2TP control messages. 869 Control Message Authentication (Section 4.3), even with an empty 870 password field, provides for a sufficient packet integrity check and 871 SHOULD always be enabled. 873 4.1.2 L2TP over UDP 875 L2TPv3 over UDP must consider other L2 tunneling protocols that may 876 be operating in the same environment, including L2TPv2 [RFC2661] and 877 L2F [RFC2341]. 879 While there are efficiencies gained by running L2TP directly over IP, 880 there are possible side effects as well. For instance, L2TP over IP 881 is not as NAT-friendly as L2TP over UDP. 883 4.1.2.1 L2TP Session Header Over UDP 885 The following session header format is utilized when operating L2TPv3 886 over UDP: 888 Figure 4.1.2.1: L2TPv3 Session Header over UDP 890 0 1 2 3 891 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 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 |T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Session ID | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Cookie (optional, maximum 64 bits)... 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 The T bit MUST be set to 0, indicating that this is a data message. 904 The x bits and Reserved field are reserved for future extensions. 905 All reserved values MUST be set to 0 on outgoing messages and ignored 906 on incoming messages. 908 The Ver field MUST be set to 3, indicating an L2TPv3 message. 910 Note that the initial bits 1, 4, 6 and 7 have meaning in L2TPv2 911 [RFC2661], and are deprecated and marked as reserved in L2TPv3. Thus, 912 for UDP mode on a system that supports both versions of L2TP, it is 913 important that the Ver field be inspected first to determine the 914 Version of the header before acting upon any of these bits. 916 The Session ID and Cookie fields are as defined in Section 4.1. 918 4.1.2.2 UDP Port Selection 920 The method for UDP Port Selection defined in this section is 921 identical to than defined for L2TPv2 [RFC2661]. 923 When negotiating a control connection over UDP, control messages MUST 924 be sent as UDP datagrams using the registered UDP port 1701 925 [RFC1700]. The initiator of an L2TP control connection picks an 926 available source UDP port (which may or may not be 1701), and sends 927 to the desired destination address at port 1701. The recipient picks 928 a free port on its own system (which may or may not be 1701) and 929 sends its reply to the initiator's UDP port and address, setting its 930 own source port to the free port it found. 932 Any subsequent traffic associated with this control connection 933 (either control traffic or data traffic from a session established 934 through this control connection) must use these same UDP ports. 936 It has been suggested that having the recipient choose an arbitrary 937 source port (as opposed to using the destination port in the packet 938 initiating the control connection, i.e., 1701) may make it more 939 difficult for L2TP to traverse some NAT devices. Implementations 940 should consider the potential implication of this capability before 941 choosing an arbitrary source port. A NAT device that can pass TFTP 942 traffic with variant UDP ports should be able to pass L2TP UDP 943 traffic since both protocols employ similar policies with regard to 944 UDP port selection. 946 4.1.2.3 UDP Checksum 948 UDP checksums MUST be enabled for control messages and MAY be enabled 949 for data messages. It should be noted that enabling checksums on 950 data packets may significantly increase the data packet processing 951 burden. 953 4.1.3 IP Fragmentation Issues 955 IP fragmentation may occur as the L2TP packet travels over the IP 956 substrate. L2TP makes no special efforts defined in this document to 957 optimize this. 959 4.2 Reliable Delivery of Control Messages 961 L2TP provides a lower level reliable delivery service for all control 962 messages. The Nr and Ns fields of the control message header (see 963 Section 3.2.1) belong to this delivery mechanism. The upper level 964 functions of L2TP are not concerned with retransmission or ordering 965 of control messages. The reliable control messaging mechanism is a 966 sliding window mechanism that provides control message retransmission 967 and congestion control. Each peer maintains separate sequence number 968 state for each control connection. 970 The message sequence number, Ns, begins at 0. Each subsequent 971 message is sent with the next increment of the sequence number. The 972 sequence number is thus a free-running counter represented modulo 973 65536. The sequence number in the header of a received message is 974 considered less than or equal to the last received number if its 975 value lies in the range of the last received number and the preceding 976 32767 values, inclusive. For example, if the last received sequence 977 number was 15, then messages with sequence numbers 0 through 15, as 978 well as 32784 through 65535, would be considered less than or equal. 979 Such a message would be considered a duplicate of a message already 980 received and ignored from processing. However, in order to ensure 981 that all messages are acknowledged properly (particularly in the case 982 of a lost ACK message), receipt of duplicate messages MUST be 983 acknowledged by the reliable delivery mechanism. This acknowledgment 984 may either piggybacked on a message in queue or sent explicitly via 985 an ACK message. 987 All control messages take up one slot in the control message sequence 988 number space, except the ACK message. Thus, Ns is not incremented 989 after an ACK message is sent. 991 The last received message number, Nr, is used to acknowledge messages 992 received by an L2TP peer. It contains the sequence number of the 993 message the peer expects to receive next (e.g. the last Ns of a non- 994 ACK message received plus 1, modulo 65536). While the Nr in a 995 received ACK message is used to flush messages from the local 996 retransmit queue (see below), the Nr of the next message sent is not 997 updated by the Ns of the ACK message. Nr SHOULD be sanity-checked 998 before flushing the retransmit queue. For instance, if the Nr 999 received in a control message is greater than the last Ns sent plus 1 1000 modulo 65536, the control message is clearly invalid. 1002 The reliable delivery mechanism at a receiving peer is responsible 1003 for making sure that control messages are delivered in order and 1004 without duplication to the upper level. Messages arriving out of 1005 order may be queued for in-order delivery when the missing messages 1006 are received. Alternatively, they may be discarded, thus requiring a 1007 retransmission by the peer. When dropping out of order control 1008 packets, Nr MAY be updated before the packet is discarded. 1010 Each control connection maintains a queue of control messages to be 1011 transmitted to its peer. The message at the front of the queue is 1012 sent with a given Ns value and is held until a control message 1013 arrives from the peer in which the Nr field indicates receipt of this 1014 message. After a period of time (a recommended default is 1 second 1015 but SHOULD be configurable) passes without acknowledgment, the 1016 message is retransmitted. The retransmitted message contains the 1017 same Ns value, but the Nr value MUST be updated with the sequence 1018 number of the next expected message. 1020 Each subsequent retransmission of a message MUST employ an 1021 exponential backoff interval. Thus, if the first retransmission 1022 occurred after 1 second, the next retransmission should occur after 2 1023 seconds has elapsed, then 4 seconds, etc. An implementation MAY 1024 place a cap upon the maximum interval between retransmissions. This 1025 cap SHOULD be no less than 8 seconds per retransmission. If no peer 1026 response is detected after several retransmissions (a recommended 1027 default is 10, but MUST be configurable), the control connection and 1028 all associated sessions MUST be cleared. As it is the first message 1029 to establish a control connection, the SCCRQ MAY employ a different 1030 retransmission maximum than other control messages in order to help 1031 facilitate failover to alternate LCCEs in a timely fashion. 1033 When a control connection is being shut down for reasons other than 1034 loss of connectivity, the state and reliable delivery mechanisms MUST 1035 be maintained and operated for the full retransmission interval after 1036 the final message StopCCN message has been sent (e.g. 1 + 2 + 4 + 8 + 1037 8... seconds), or until the StopCCN message itself has been 1038 acknowledged. 1040 A sliding window mechanism is used for control message transmission 1041 and retransmission. Consider two peers, A and B. Suppose A 1042 specifies a Receive Window Size AVP with a value of N in the SCCRQ or 1043 SCCRP message. B is now allowed to have a maximum of N outstanding 1044 (e.g. unacknowledged) control messages. Once N messages have been 1045 sent, B must wait for an acknowledgment from A that advances the 1046 window before sending new control messages. An implementation may 1047 advertise a non-zero receive window as small or as large as it 1048 wishes, depending on its own ability to process incoming messages 1049 before sending an acknowledgement. Each peer MUST limit the number of 1050 unacknowledged messages it will send before receiving an 1051 acknowledgement by this Receive Window Size. The actual internal 1052 unacknowledged message send-queue depth may be further limited by 1053 local resource allocation or by dynamic slow-start and congestion- 1054 avoidance mechanisms. 1056 When retransmitting control messages, a slow start and congestion 1057 avoidance window adjustment procedure SHOULD be utilized. A 1058 recommended procedure is described in Appendix A. A peer MAY drop 1059 messages, but MUST NOT actively delay acknowledgment of messages as a 1060 technique for flow control of control messages. Appendix B contains 1061 examples of control message transmission, acknowledgment, and 1062 retransmission. 1064 4.3 Control Connection and Control Message Authentication 1066 L2TP incorporates an optional authentication and integrity check for 1067 all control messages. This mechanism consists of a computed one-way 1068 hash over the header and body of the L2TP control message, a pre- 1069 configured shared secret, and a local and remote nonce (random value) 1070 exchanged via the Nonce AVP. This per-message authentication and 1071 integrity check is designed to perform a mutual authentication 1072 between L2TP nodes, integrity checking of all control messages, and 1073 guard against control message spoofing and replay attacks that would 1074 otherwise be trivial to mount. 1076 A shared secret (password) MUST exist between communicating L2TP 1077 nodes to obtain the benefit of message or peer authentication. If a 1078 shared secret is not configured on either node, the per-message 1079 integrity check may still be performed using an empty shared secret 1080 of zero length. See Section 5.4.3 for details on calculation of the 1081 Message Digest and construction of the Nonce and Message Digest AVPs. 1083 L2TPv3 Control Connection and Control Message Authentication is 1084 similar to L2TPv2 [RFC2661] Tunnel Authentication in its use of a 1085 shared secret for peer authentication, use of a one-way hash 1086 calculation, and exchange of a random value. The principal difference 1087 is that, instead of computing the hash over selected contents of a 1088 received control message (e.g. the Challenge AVP and Message Type) as 1089 in L2TPv2, the entire message is used in the hash in L2TPv3. In 1090 addition, instead of including the hash digest in just the SCCRP and 1091 SCCCN messages, it is now included in all L2TP messages. 1093 The Control Message Authentication mechanism is optional, and may be 1094 disabled if both peers agree. For example, if IPsec is already being 1095 used for security and integrity checking between the LCCEs, the L2TP 1096 mechanism defined here becomes redundant and may be disabled. 1097 Presence of the Message Digest AVP in an SCCRQ or SCCRP message 1098 serves as the indication to a peer that Control Message 1099 Authentication is enabled. If an SCCRQ or SCCRP contains a Message 1100 Digest AVP, the receiver of the message MUST respond with a Message 1101 Digest AVP in all subsequent messages sent. If an SCCRQ or SCCRP is 1102 received with a missing or incorrect Message Digest AVP value, a 1103 StopCCN MAY be sent with the Result Code set to 4 (see Section 1104 5.4.2). Care should be taken to rate-limit such responses as to not 1105 end up in a denial of service situation responding to rogue SCCRQ or 1106 SCCRP control messages. All other control messages with missing or 1107 incorrect Message Digest AVPs MUST be dropped. 1109 4.4 Keepalive (Hello) 1111 A keepalive mechanism is employed by L2TP to detect loss of 1112 connectivity between a pair of LCCEs. This is accomplished by 1113 injecting Hello control messages (see Section 6.5) after a period of 1114 time has elapsed since the last data message or control message was 1115 received on an L2TP session or control connection, respectively. As 1116 with any other control message, if the Hello message is not reliably 1117 delivered, the sending LCCE declares that the control connection is 1118 down and resets its state for the control connection. This behavior 1119 ensures that a connectivity failure between the LCCEs is detected 1120 independently by each end of a control connection. 1122 Since the control channel is operated in-band with data traffic over 1123 the PSN, this single mechanism can be used to infer basic data 1124 connectivity between a pair of LCCEs for all sessions associated with 1125 the control connection. 1127 Periodic keepalive for the control connection MUST be implemented by 1128 sending a Hello if a period of time (a recommended default is 60 1129 seconds, but MUST be configurable) has passed without receiving any 1130 message (data or control) from the peer. An LCCE sending Hello 1131 messages across multiple control connections between the same LCCE 1132 endpoints MUST employ a jittered timer mechanism to prevent grouping 1133 of Hello messages. 1135 4.5 Forwarding Session Data Frames 1137 Once session establishment is complete, circuit frames are received 1138 at an LCCE, encapsulated in L2TP (with appropriate attention to 1139 framing as described in documents for the particular pseudowire 1140 type), and forwarded over the appropriate session. For every 1141 outgoing data message, the sender places the identifier specified in 1142 the Local Session ID AVP (received from peer during session 1143 establishment) in the Session ID field of the L2TP data header. In 1144 this manner, session frames are multiplexed and demultiplexed between 1145 a given pair of LCCEs. Multiple control connections may exist 1146 between a given pair of LCCEs, and multiple sessions may be 1147 associated with a given control connection. 1149 The peer LCCE receiving the L2TP data packet identifies the session 1150 with which the packet is associated by the Session ID in the data 1151 packet's header. The LCCE then checks the Cookie field in the data 1152 packet against the Cookie value received in the Assigned Cookie AVP 1153 during session establishment. It is important for implementers to 1154 note that the Cookie field check occurs after looking up the session 1155 context by the Session ID, and as such consists merely of a value 1156 match of the Cookie field and that stored in the retrieved context. 1157 There is no need to perform a lookup across the Session ID and Cookie 1158 as a single value. Any received data packets that contain invalid 1159 Session IDs or associated Cookie values MUST be dropped. Finally, 1160 the LCCE either forwards the network packet within the tunneled frame 1161 (e.g., as an LNS) or switches the frame to a circuit (e.g., as an 1162 LAC). 1164 4.6 Default L2-Specific Sublayer 1166 This document defines a default L2-Specific Sublayer (see Section 1167 3.2.2) format that a pseudowire may use for features such as basic 1168 sequencing support, marking of packets with a single high-priority 1169 bit, or other general per-data-packet control operations. The 1170 default L2-Specific Sublayer SHOULD be used by a given PW type to 1171 support these features if it is adequate, and its presence is 1172 requested by a peer during session negotiation. Alternative 1173 sublayers MAY be defined (e.g. an encapsulation with a larger 1174 Sequence Number field or timing information) and identified for use 1175 via the L2-Specific Sublayer Type AVP. 1177 Figure 4.6: Default L2-Specific Sublayer Format 1179 0 1 2 3 1180 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 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 |P|S|x|x|x|x|x|x| Sequence Number | 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 The P (Priority) bit is used to identify a data packet that should be 1186 dropped only as a last resort after being received by an L2TP peer. 1187 This bit should be set to 1 for any traffic that should be given 1188 higher priority than other data traffic in a congested environment. 1189 For example, end-to-end L2 keepalive packets (e.g. PPP keepalives) or 1190 other control packets vital to the life of the circuit or network may 1191 need special handling by an LCCE upon receipt. This is not a 1192 replacement for, or to be used as, a per-hop QoS method of any sort. 1193 It is only to be used by the L2TP receiving node to prioritize 1194 incoming traffic. 1196 The S (Sequence) bit is set to 1 when the Sequence Number contains a 1197 valid number for this sequenced frame. If the S bit is set to zero, 1198 the Sequence Number contents are undefined and MUST be ignored by the 1199 receiver. 1201 The Sequence Number field contains a free-running counter of 2^24 1202 sequence numbers. If the number in this field is valid, the S bit 1203 MUST be set to 1. The Sequence Number begins at zero, which is a 1204 valid sequence number. (In this way, implementations inserting 1205 sequence numbers do not have to "skip" zero when incrementing.) The 1206 sequence number in the header of a received message is considered 1207 less than or equal to the last received number if its value lies in 1208 the range of the last received number and the preceding (2^23-1) 1209 values, inclusive. 1211 4.6.1 Sequencing Data Packets 1213 The Sequence Number field may be used to detect lost, duplicate, or 1214 out-of-order packets within a given session. 1216 When L2 frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP 1217 data channel, this part of the link has the characteristic of being 1218 able to reorder, duplicate, or silently drop packets. Reordering may 1219 break some non-IP protocols or L2 control traffic being carried by 1220 the link. Silent dropping or duplication of packets may break 1221 protocols that assume per-packet indications of error, such as TCP 1222 header compression. While a common mechanism for packet sequence 1223 detection is provided, the sequence dependency characteristics of 1224 individual protocols are outside the scope of this document. 1226 If any protocol being transported by over L2TP data channels cannot 1227 tolerate misordering of data packets, packet duplication, or silent 1228 packet loss, sequencing may be enabled on some or all packets by 1229 using the S bit and Sequence Number field defined in the default 1230 L2-Specific Sublayer(see Section 4.6). For a given L2TP session, 1231 each LCCE is responsible for communicating to its peer the level of 1232 sequencing support that it requires of data packets that it receives. 1233 Mechanisms to advertise this information during session negotiation 1234 are provided (see Data Sequencing AVP in Section 5.4.4). 1236 When determining whether a packet is in or out of sequence, an 1237 implementation SHOULD utilize a method that is resilient to temporary 1238 dropouts in connectivity coupled with high per-session packet rates. 1239 The recommended method is outlined in Appendix C. 1241 4.7 L2TPv2/v3 Interoperability and Migration 1243 L2TPv2 and L2TPv3 environments should be able to coexist while a 1244 migration to L2TPv3 is made. Migration issues are discussed for each 1245 media type in this section. Most issues apply only to 1246 implementations that require both L2TPv2 and L2TPv3 operation. 1247 However, even L2TPv3-only implementations must at least be mindful of 1248 these issues in order to interoperate with implementations that 1249 support both versions. 1251 4.7.1 L2TPv3 over IP 1253 L2TPv3 implementations running strictly over IP with no desire to 1254 interoperate with L2TPv2 implementations may safely disregard most 1255 migration issues from L2TPv2. All control messages and data messages 1256 are sent as described in this document, without normative reference 1257 to RFC2661. 1259 If one wishes to tunnel PPP over L2TPv3, and fallback to L2TPv2 only 1260 if it is not available, then L2TPv3 over UDP with the automatic 1261 fallback as described in section 4.7.3 MUST be used. There is no 1262 deterministic method for automatic fallback from L2TPv3 over IP to 1263 either L2TPv2 or L2TPv3 over UDP. One could infer whether L2TPv3 over 1264 IP is supported by sending an SCCRQ and waiting for a response, but 1265 this could be problematic during periods of packet loss between L2TP 1266 nodes. 1268 4.7.2 L2TPv3 over UDP 1270 The format of the L2TPv3 over UDP header is defined in Section 1271 4.1.2.1. 1273 When operating over UDP, L2TPv3 uses the same port (1701) as L2TPv2 1274 and shares the first two octets of header format with L2TPv2. The Ver 1275 field is used to distinguish L2TPv2 packets from L2TPv3 packets. If 1276 an implementation is capable of operating in L2TPv2 or L2TPv3 modes, 1277 it is possible to automatically detect whether a peer can support 1278 L2TPv2 or L2TPv3 and operate accordingly. The details of this 1279 fallback capability is defined in the following section. 1281 4.7.3 Automatic L2TPv2 Fallback 1283 When running over UDP, an implementation may detect whether a peer is 1284 L2TPv3-capable by sending a special SCCRQ that is properly formatted 1285 for both L2TPv2 and L2TPv3. This is accomplished by sending an SCCRQ 1286 with its Ver field set to 2 (for L2TPv2), and ensuring that any 1287 L2TPv3-specific AVPs (i.e. AVPs present within this document and not 1288 defined within RFC 2661) within the message are sent with each M bit 1289 set to 0, and all L2TPv2 AVPs present as they would be for L2TPv2. 1290 This is done so that L2TPv3 AVPs will be ignored by an L2TPv2-only 1291 implementation. Note that, in both L2TPv2 and L2TPv3, the value 1292 contained in the space of the control message header utilized by the 1293 32-bit Control Connection ID in L2TPv3, and the 16-bit Tunnel ID and 1294 16-bit Session ID in L2TPv2, is always 0 for an SCCRQ. This 1295 effectively hides the fact that there are a pair of 16-bit fields in 1296 L2TPv2, and a single 32-bit field in L2TPv3. 1298 If the peer implementation is L2TPv3-capable, a control message with 1299 Ver set to 3 and corresponding header and message format will be sent 1300 in response to the SCCRQ. Operation may then continue as L2TPv3. If 1301 a message is received with Ver set to 2, it must be assumed that the 1302 peer implementation is L2TPv2-only and fallback to L2TPv2 mode may 1303 safely occur. 1305 Note Well: The L2TPv2/v3 auto-detection mode requires that all L2TPv3 1306 implementations over UDP be liberal in acceptance of an SCCRQ control 1307 message with the Ver field set to 2 or 3 and the presence of 1308 L2TPv2-specific AVPs. An L2TPv3-only implementation MUST ignore all 1309 L2TPv2 AVPs (e.g. those defined in RFC 2661 and not in this document) 1310 within an SCCRQ with the Ver field set to 2 (even if the M bit is set 1311 on the L2TPv2-specific AVPs). 1313 5. Control Message Attribute Value Pairs 1315 To maximize extensibility while permitting interoperability, a 1316 uniform method for encoding message types is used throughout L2TP. 1317 This encoding will be termed AVP (Attribute Value Pair) for the 1318 remainder of this document. 1320 5.1 AVP Format 1322 Each AVP is encoded as follows: 1324 Figure 5.1: AVP Format 1326 0 1 2 3 1327 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 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 |M|H| rsvd | Length | Vendor ID | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Attribute Type | Attribute Value ... 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 (until Length is reached) | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 The first six bits comprise a bit mask that describes the general 1337 attributes of the AVP. Two bits are defined in this document; the 1338 remaining bits are reserved for future extensions. Reserved bits 1339 MUST be set to 0. An AVP received with a reserved bit set to 1 MUST 1340 be treated as an unrecognized AVP. 1342 Mandatory (M) bit: Controls the behavior required of an 1343 implementation that receives an unrecognized AVP. The M bit of a 1344 given AVP MUST only be inspected and acted upon if the AVP is 1345 unrecognized (see Section 5.2). 1347 Hidden (H) bit: Identifies the hiding of data in the Attribute Value 1348 field of an AVP. This capability can be used to avoid the passing of 1349 sensitive data, such as user passwords, as cleartext in an AVP. 1350 Section 5.3 describes the procedure for performing AVP hiding. 1352 Length: Contains the number of octets (including the Overall Length 1353 and bit mask fields) contained in this AVP. The Length may be 1354 calculated as 6 + the length of the Attribute Value field in octets. 1355 The field itself is 10 bits, permitting a maximum of 1023 octets of 1356 data in a single AVP. The minimum Length of an AVP is 6. If the 1357 Length is 6, then the Attribute Value field is absent. 1359 Vendor ID: The IANA assigned "SMI Network Management Private 1360 Enterprise Codes" [RFC1700] value. The value 0, corresponding to 1361 IETF adopted attribute values, is used for all AVPs defined within 1362 this document. Any vendor wishing to implement its own L2TP 1363 extensions can use its own Vendor ID along with private Attribute 1364 values, guaranteeing that they will not collide with any other 1365 vendor's extensions or future IETF extensions. Note that there are 1366 16 bits allocated for the Vendor ID, thus limiting this feature to 1367 the first 65,535 enterprises. 1369 Attribute Type: A 2-octet value with a unique interpretation across 1370 all AVPs defined under a given Vendor ID. 1372 Attribute Value: This is the actual value as indicated by the Vendor 1373 ID and Attribute Type. It follows immediately after the Attribute 1374 Type field and runs for the remaining octets indicated in the Length 1375 (i.e., Length minus 6 octets of header). This field is absent if the 1376 Length is 6. 1378 5.2 Mandatory AVPs and Setting the M Bit 1380 If the M bit is set on an AVP that is unrecognized by its recipient, 1381 the session or control connection associated with the contorl message 1382 containing the AVP MUST be shutdown. If the control message 1383 containing the unrecognized AVP is associated with a session (e.g. an 1384 ICRQ, ICRP, ICCN, SLI, etc.) then the session MUST be issued a CDN 1385 with a Result Code of 2 and Error Code of 8 as defined in section 1386 5.4.2. and shutdown. If the control message containing the 1387 unrecognized AVP is associated with establishment or maintenance of a 1388 Control Connection (e.g. SCCRQ, SCCRP, SCCCN, Hello) then the 1389 associated Control Connection MUST be issued a StopCCN with Result 1390 Code of 2 and Error Code of 8 as defined in section 5.4.2. and 1391 shutdown. If the M bit is not set on an unrecognized AVP, the AVP 1392 MUST be ignored when received, processing the control message as if 1393 the AVP was not present. 1395 Receipt of an unrecognized AVP that has the M bit set is catastrophic 1396 to the session or control connection with which it is associated. 1397 Thus, the M bit should only be set for AVPs that are deemed crucial 1398 to proper operation of the session or control connection by the 1399 sender. AVPs that are considered crucial by the sender may vary by 1400 application and configured options. In no case shall a receiver of 1401 an AVP "validate" if the M bit is set on a recognized AVP. If the AVP 1402 is recognized (as all AVPs defined in this document MUST be for a 1403 compliant L2TPv3 specification), then by definition the M bit is of 1404 no consequence. 1406 The sender of an AVP is free to set its M bit to 1 or 0 based on 1407 whether the configured application strictly requires the value 1408 contained in the AVP to be recognized or not. For example, "Automatic 1409 L2TPv2 Fallback" (Section 4.7.3), requires the setting of the M bit 1410 on all new L2TPv3 AVPs to zero if fallback to L2TPv2 is supported and 1411 desired, and 1 if not. 1413 The M bit is useful as extra assurance for support of critical AVP 1414 extensions. However, more explicit methods may be available to 1415 determine support for a given feature rather than using the M bit 1416 alone. For example, if a new AVP is defined in a message for which 1417 there is always a message reply (i.e. an ICRQ, ICRP, SCCRQ or SCCRP 1418 message) rather than simply sending an AVP in the message with the M 1419 bit set, availability of the extension may be identified by sending 1420 an AVP in the request message and expecting a corresponding AVP in a 1421 reply message. This more explicit method, when possible, is 1422 preferred. 1424 The M bit also plays a role in determining whether or not a malformed 1425 or out-of-range value within an AVP should be ignored or result in 1426 termination of a session or control channel. See Section 7.1 for more 1427 details on this. 1429 5.3 Hiding of AVP Attribute Values 1431 The H bit in the header of each AVP provides a mechanism to indicate 1432 to the receiving peer whether the contents of the AVP are hidden or 1433 present in cleartext. This feature can be used to hide sensitive 1434 control message data such as user passwords, IDs, or other vital 1435 information. 1437 The H bit MUST only be set if (1) a shared secret exists between the 1438 LCCEs and (2) Control Connection and Control Message Authentication 1439 is enabled (see Section 4.3). If the H bit is set in any AVP(s) in a 1440 given control message, a Random Vector AVP must also be present in 1441 the message and MUST precede the first AVP having an H bit of 1. 1443 The shared secret between LCCEs is used to derive a unique shared key 1444 for hiding and unhiding calculations. The derived shared key is 1445 obtained via a one-way HMAC-MD5 hash [RFC1321] on the shared secret 1446 concatenated with a single octet containing the value 1. 1448 shared_key = HMAC_MD5 (shared_secret | 1) 1450 Hiding an AVP value is done in several steps. The first step is to 1451 take the length and value fields of the original (cleartext) AVP and 1452 encode them into a Hidden AVP Subformat as follows: 1454 Figure 5.3: Hidden AVP Subformat 1456 0 1 2 3 1457 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 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | Length of Original Value | Original Attribute Value ... 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 ... | Padding ... 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 Length of Original Attribute Value: This is length of the Original 1465 Attribute Value to be obscured in octets. This is necessary to 1466 determine the original length of the Attribute Value that is lost 1467 when the additional Padding is added. 1469 Original Attribute Value: Attribute Value that is to be obscured. 1471 Padding: Random additional octets used to obscure length of the 1472 Attribute Value that is being hidden. 1474 To mask the size of the data being hidden, the resulting subformat 1475 MAY be padded as shown above. Padding does NOT alter the value 1476 placed in the Length of Original Attribute Value field, but does 1477 alter the length of the resultant AVP that is being created. For 1478 example, if an Attribute Value to be hidden is 4 octets in length, 1479 the unhidden AVP length would be 10 octets (6 + Attribute Value 1480 length). After hiding, the length of the AVP will become 6 + 1481 Attribute Value length + size of the Length of Original Attribute 1482 Value field + Padding. Thus, if Padding is 12 octets, the AVP length 1483 will be 6 + 4 + 2 + 12 = 24 octets. 1485 Next, an MD5 hash is performed (in network byte order) on the 1486 concatenation of the following: 1488 + the 2-octet Attribute number of the AVP 1489 + the shared key 1490 + an arbitrary length random vector 1492 The value of the random vector used in this hash is passed in the 1493 value field of a Random Vector AVP. This Random Vector AVP must be 1494 placed in the message by the sender before any hidden AVPs. The same 1495 random vector may be used for more than one hidden AVP in the same 1496 message. If a different random vector is used for the hiding of 1497 subsequent AVPs, then a new Random Vector AVP must be placed in the 1498 command message before the first AVP to which it applies. 1500 The MD5 hash value is then XORed with the first 16-octet (or less) 1501 segment of the Hidden AVP Subformat and placed in the Attribute Value 1502 field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 1503 octets, the Subformat is transformed as if the Attribute Value field 1504 had been padded to 16 octets before the XOR. Only the actual octets 1505 present in the Subformat are modified, and the length of the AVP is 1506 not altered. 1508 If the Subformat is longer than 16 octets, a second one-way MD5 hash 1509 is calculated over a stream of octets consisting of the shared key 1510 followed by the result of the first XOR. That hash is XORed with the 1511 second 16-octet (or less) segment of the Subformat and placed in the 1512 corresponding octets of the Value field of the Hidden AVP. 1514 If necessary, this operation is repeated, with the shared key used 1515 along with each XOR result to generate the next hash to XOR the next 1516 segment of the value with. 1518 The hiding method was adapted from [RFC2865], which was taken from 1519 the "Mixing in the Plaintext" section in the book "Network Security" 1520 by Kaufman, Perlman and Speciner [KPS]. A detailed explanation of 1521 the method follows: 1523 Call the shared key S, the Random Vector RV, and the Attribute Value 1524 AV. Break the value field into 16-octet chunks p1, p2, etc., with 1525 the last one padded at the end with random data to a 16-octet 1526 boundary. Call the ciphertext blocks c(1), c(2), etc. We will also 1527 define intermediate values b1, b2, etc. 1529 b1 = MD5(AV + S + RV) c(1) = p1 xor b1 1530 b2 = MD5(S + c(1)) c(2) = p2 xor b2 1531 . . 1532 . . 1533 . . 1534 bi = MD5(S + c(i-1)) c(i) = pi xor bi 1536 The String will contain c(1)+c(2)+...+c(i), where + denotes 1537 concatenation. 1539 On receipt, the random vector is taken from the last Random Vector 1540 AVP encountered in the message prior to the AVP to be unhidden. The 1541 above process is then reversed to yield the original value. 1543 5.4 AVP Summary 1545 The following sections contain a list of all L2TP AVPs defined in 1546 this document. 1548 Following the name of the AVP is a list indicating the message types 1549 that utilize each AVP. After each AVP title follows a short 1550 description of the purpose of the AVP, a detail (including a graphic) 1551 of the format for the Attribute Value, and any additional information 1552 needed for proper use of the AVP. 1554 5.4.1 General Control Message AVPs 1556 Message Type (All Messages) 1558 The Message Type AVP, Attribute Type 0, identifies the control 1559 message herein and defines the context in which the exact meaning of 1560 the following AVPs will be determined. 1562 The Attribute Value field for this AVP has the following format: 1564 0 1 1565 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 | Message Type | 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 The Message Type is a 2-octet unsigned integer. 1572 The Message Type AVP MUST be the first AVP in a message, immediately 1573 following the control message header (defined in Section 3.2.1). See 1574 Section 3.1 for the list of defined control message types and their 1575 identifiers. 1577 The Mandatory (M) bit within the Message Type AVP has special 1578 meaning. Rather than an indication as to whether the AVP itself 1579 should be ignored if not recognized, it is an indication as to 1580 whether the control message itself should be ignored. If the M bit 1581 is set within the Message Type AVP and the Message Type is unknown to 1582 the implementation, the control connection MUST be cleared. If the M 1583 bit is not set, then the implementation may ignore an unknown message 1584 type. The M bit MUST be set to 1 for all message types defined in 1585 this document. This AVP MAY NOT be hidden (the H bit MUST be 0). 1586 The Length of this AVP is 8. 1588 A vendor-specific control message may be defined by setting the 1589 Vendor ID of the Message Type AVP to a value other than the IETF 1590 Vendor ID of 0 (see Section 5.1). The Message Type AVP MUST still be 1591 the first AVP in the control message. 1593 Message Digest (All Messages) 1595 The Message Digest AVP, Attribute Type AVP-TBA-1, is used as an 1596 integrity check and authentication of the L2TP Control Message 1597 header and body. 1599 The Attribute Value field for this AVP has the following format: 1601 0 1 2 3 1602 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 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 | Digest Type | Message Digest ... 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 ... (16 octets) | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 Where Digest Type is a one octet integer indicating the Digest 1613 calculation algorithm: 1614 0 HMAC-MD5 [RFC1321] 1615 1 HMAC-SHA-1 [RFC2104] 1617 Digest type 0 (HMAC-MD5) MUST be supported, Digest Type 1 (HMAC- 1618 SHA-1) MAY be supported. 1620 The Message Digest is of variable length and contains the result 1621 of the control message authenticity and integrity calculation. For 1622 Digest Type 0 (HMAC-MD5) the length of the digest MUST be 160 1623 bits. The local_nonce and remote_nonce are advertised via the 1624 Control Message Authentication Nonce AVP, also defined in this 1625 section. 1627 If Control Connection and Control Message Authentication is 1628 enabled, the Message Digest AVP MUST present in all messages and 1629 MUST be placed immediately after the Message Type AVP. This forces 1630 the Message Digest to be present within each message at a well- 1631 known and fixed offset. 1633 The shared secret between LCCEs is used to derive a unique shared 1634 key for Control Connection and Control Message Authentication 1635 calculations. The derived shared key is obtained via a one-way 1636 HMAC-MD5 hash [RFC1321] on the shared secret concatenated with a 1637 single octet containing the value 2. 1639 shared_key = HMAC_MD5 (shared_secret | 2) 1641 Calculation of the digest is as follows for all messages other 1642 than the SCCRQ: 1644 Digest = Hash (local_nonce | remote_nonce | shared_key | 1645 control_message) 1647 Hash: Hashing algorithm identified by the Digest Type 1649 local_nonce: Nonce chosen locally and advertised to the remote 1650 LCCE. 1652 remote_nonce: Nonce received from the remote LCCE 1654 shared_key: Derived shared key for this Control Connection 1655 control_message: The entire contents of the L2TP Control 1656 Message, including the Control Message header and all AVPs. 1657 Note that the Control Message header in this case begins after 1658 the 0 Session ID (see Section 4.1.1.2) when running over IP, 1659 and after the UDP header when running over UDP (see Section 1660 4.1.2.1). 1662 When calculating the Message Digest, the Message Digest AVP MUST 1663 be present within the control message with the Digest Type set to 1664 its proper value, but the Message Digest itself set to zeros. 1666 When receiving a control message, the contents of the Message 1667 Digest AVP MUST be compared against the expected digest value 1668 based on local calculation. This is done by performing the same 1669 digest calculation above, with the local_nonce and remote_nonce 1670 reversed. This message authenticity and integrity checking MUST be 1671 performed before utilizing any information contained within the 1672 control message. If the calculation fails, the message MUST be 1673 dropped. 1675 The SCCRQ has special treatment as it is the initial message 1676 commencing a new Control Connection. As such, there is only one 1677 nonce available. Since the nonce is present within the message 1678 itself as part of the Control Message Authentication Nonce AVP, 1679 there is no need to use it in the calculation explicitly. 1680 Calculation of the SCCRQ Digest is performed as follows: 1682 Digest = Hash (shared_key | control_message) 1684 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1685 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1686 Length is 28 for Digest Type 1 (HMAC-MD5), and may vary for other 1687 digest types. 1689 Control Message Authentication Nonce (SCCRQ, SCCRP) 1691 The Control Message Authentication Nonce AVP, Attribute Type 1692 AVP-TBA-15, MUST contain a cryptographically random value 1693 [RFC1750]. This value is used for Control Message 1694 Authentication. 1696 The Attribute Value field for this AVP has the following 1697 format: 1699 0 1 2 3 1700 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | Nonce ... (arbitrary number of octets) 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 The Nonce is of arbitrary length, though at least 16 octets is 1706 recommended. The Nonce contains the random value for use in 1707 the Control Message Authentication hash calculation (see 1708 Message Digest AVP definition in this section). 1710 If Control Connection and Message Authentication is enabled, 1711 this AVP MUST be present in the SCCRQ and SCCRP messages. 1713 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit 1714 for this AVP SHOULD be set to 1, but MAY vary (see Section 1715 5.2). The Length of this AVP is 6 plus the length of the 1716 Nonce. 1718 Random Vector (All Messages) 1720 The Random Vector AVP, Attribute Type 36, MUST contain a 1721 cryptographically random value [RFC1750]. This value is used for AVP 1722 Hiding. 1724 The Attribute Value field for this AVP has the following format: 1726 0 1 2 3 1727 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 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 | Random Octet String ... (arbitrary number of octets) 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 The Random Octet String is of arbitrary length, though at least 16 1733 octets is recommended. The string contains the random vector for use 1734 in computing the MD5 hash to retrieve or hide the Attribute Value of 1735 a hidden AVP (see Section 5.3). 1737 More than one Random Vector AVP may appear in a message, in which 1738 case a hidden AVP uses the Random Vector AVP most closely preceding 1739 it. As such, at least one Random Vector AVP MUST precede the first 1740 AVP with the H bit set. 1742 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1743 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1744 Length of this AVP is 6 plus the length of the Random Octet String. 1746 5.4.2 Result and Error Codes 1748 Result Code (StopCCN, CDN) 1750 The Result Code AVP, Attribute Type 1, indicates the reason for 1751 terminating the control channel or session. 1753 The Attribute Value field for this AVP has the following format: 1755 0 1 2 3 1756 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 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 | Result Code | Error Code (optional) | 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 | Error Message ... (optional, arbitrary number of octets) | 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 The Result Code is a 2-octet unsigned integer. The optional Error 1764 Code is a 2-octet unsigned integer. An optional Error Message can 1765 follow the Error Code field. Presence of the Error Code and Message 1766 is indicated by the AVP Length field. The Error Message contains an 1767 arbitrary string providing further (human-readable) text associated 1768 with the condition. Human-readable text in all error messages MUST 1769 be provided in the UTF-8 charset using the Default Language 1770 [RFC2277]. 1772 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1773 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1774 Length is 8 if there is no Error Code or Message, 10 if there is an 1775 Error Code and no Error Message, or 10 plus the length of the Error 1776 Message if there is an Error Code and Message. 1778 Defined Result Code values for the StopCCN message are as follows: 1780 0 - Reserved. 1781 1 - General request to clear control connection. 1782 2 - General error, Error Code indicates the problem. 1783 3 - Control channel already exists. 1784 4 - Requester is not authorized to establish a control channel. 1785 5 - The protocol version of the requester is not supported, 1786 Error Code indicates highest version supported. 1787 6 - Requester is being shut down. 1788 7 - Finite state machine error or timeout 1790 General Result Code values for the CDN message are as follows: 1792 0 - Reserved. 1793 1 - Session disconnected due to loss of carrier or circuit disconnect. 1795 2 - Session disconnected for the reason indicated in Error Code. 1796 3 - Session disconnected for administrative reasons. 1797 4 - Session establishment failed due to lack of appropriate 1798 facilities being available (temporary condition). 1799 5 - Session establishment failed due to lack of appropriate 1800 facilities being available (permanent condition). 1801 6 - 11 Reserved (PPP-specific codes defined outside this document). 1802 RC-TBA-1 - Session not established due to losing tie breaker. 1803 RC-TBA-2 - Session not established due to unsupported PW type. 1804 RC-TBA-3 - Session not established, sequencing required without valid 1805 L2-Specific Sublayer. 1806 RC-TBA-4 - Finite state machine error or timeout. 1808 Additional service-specific Result Codes are defined outside this 1809 document. 1811 The Error Codes defined below pertain to types of errors that are not 1812 specific to any particular L2TP request, but rather to protocol or 1813 message format errors. If an L2TP reply indicates in its Result Code 1814 that a general error occurred, the General Error value should be 1815 examined to determine what the error was. The currently defined 1816 General Error codes and their meanings are as follows: 1818 0 - No general error. 1819 1 - No control connection exists yet for this pair of LCCEs. 1820 2 - Length is wrong. 1821 3 - One of the field values was out of range. 1822 4 - Insufficient resources to handle this operation now. 1823 5 - Invalid Session ID. 1824 6 - A generic vendor-specific error occurred. 1825 7 - Try another. If initiator is aware of other possible responder 1826 destinations, it should try one of them. This can be 1827 used to guide an LAC or LNS based on policy. 1828 8 - The session or control connection was shut down due to receipt of 1829 an unknown AVP with the M bit set (see Section 5.2). The Error 1830 Message SHOULD contain the attribute of the offending AVP in 1831 (human-readable) text form. 1832 9 - Try another directed. If an LAC or LNS is aware of other possible 1833 destinations, it should inform the initiator of the control 1834 connection or session. The Error Message MUST contain a 1835 comma-separated list of addresses from which the initiator may 1836 choose. If the L2TP data channel runs over IPv4, then this would 1837 be a comma-separated list of IP addresses in the canonical 1838 dotted-decimal format (e.g. "10.0.0.1, 10.0.0.2, 10.0.0.3") in the 1839 UTF-8 charset using the Default Language [RFC2277]. If there are 1840 no servers for the LAC or LNS to suggest, then Error Code 7 should 1841 be used. The delimiter between addresses MUST be precisely a 1842 single comma and a single space. 1844 When a General Error Code of 6 is used, additional information about 1845 the error SHOULD be included in the Error Message field. A vendor- 1846 specific AVP MAY be sent to more precisely detail a vendor-specific 1847 problem. 1849 5.4.3 Control Connection Management AVPs 1851 Control Connection Tie Breaker (SCCRQ) 1853 The Control Connection Tie Breaker AVP, Attribute Type 5, indicates 1854 that the sender desires a single control connection to exist between 1855 a given pair of LCCEs. 1857 The Attribute Value field for this AVP has the following format: 1859 0 1 2 3 1860 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 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 | Control Connection Tie Breaker Value ... 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1864 ... (64 bits) | 1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 The Control Connection Tie Breaker Value is an 8-octet random value 1868 that is used to choose a single control connection when two LCCEs 1869 request a control connection concurrently. The recipient of a SCCRQ 1870 must check to see if a SCCRQ has been sent to the peer; if so, a tie 1871 has been detected. In this case, the LCCE must compare its Control 1872 Connection Tie Breaker value with the one received in the SCCRQ. The 1873 lower value "wins", and the "loser" MUST discard its control 1874 connection, sending a StopCCN if the SCCRQ that it had sent was 1875 acknowledged by the receiving peer. In the case in which a tie 1876 breaker is present on both sides and the value is equal, both sides 1877 MUST discard their control connections and restart control connection 1878 negotiation with a new, random tie breaker value. 1880 If a tie breaker is received and an outstanding SCCRQ has no tie 1881 breaker value, the initiator that included the Control Connection Tie 1882 Breaker AVP "wins". If neither side issues a tie breaker, then two 1883 separate control connections are opened. 1885 Applications which employ a distinct and well-known initiator have no 1886 need for tie-breaking, and this AVP MAY be omitted and the tie- 1887 breaking functionality disabled. Applications which require tie- 1888 breaking also require that an LCCE be uniquely identifiable upon 1889 receipt of an SCCRQ. For L2TP over IP, this MUST be accomplished via 1890 the Router ID AVP. 1892 Note that in [RFC2661], this AVP was referred to as the "Tie-Breaker 1893 AVP". Here, the AVP serves the same purpose and has the same 1894 attribute value and composition. The name was changed simply to 1895 distinguish between the Session and Control Connection Tie Breaker 1896 AVP. 1898 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1899 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1900 Length of this AVP is 14. 1902 Host Name (SCCRQ, SCCRP) 1904 The Host Name AVP, Attribute Type 7, indicates the name of the 1905 issuing LAC or LNS, encoded in the US-ASCII charset. 1907 The Attribute Value field for this AVP has the following format: 1909 0 1 2 3 1910 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 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 | Host Name ... (arbitrary number of octets) 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 The Host Name is of arbitrary length, but MUST be at least 1 octet. 1917 This name should be as broadly unique as possible; for hosts 1918 participating in DNS [RFC1034], a host name with fully qualified 1919 domain would be appropriate. The Host Name AVP and/or Router ID AVP 1920 MUST be used to identify an LCCE as described in Section 3.3. 1922 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1923 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1924 Length of this AVP is 6 plus the length of the Host Name. 1926 Router ID (SCCRQ, SCCRP) 1928 The Router ID AVP, Attribute Type AVP-TBA-2, is an identifier used to 1929 identify an LCCE for control connection setup, tie breaking, and/or 1930 tunnel authentication. 1932 The Attribute Value field for this AVP has the following format: 1934 0 1 2 3 1935 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 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 | Router Identifier | 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 The Router Identifier is a 4-octet unsigned integer. Its value is 1941 unique for a given LCCE, per Section 8.1 of [RFC2072]. The Host Name 1942 AVP and/or Router ID AVP MUST be used to identify an LCCE as 1943 described in Section 3.3. 1945 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1946 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1947 Length of this AVP is 10. 1949 Vendor Name (SCCRQ, SCCRP) 1951 The Vendor Name AVP, Attribute Type 8, contains a vendor-specific 1952 (possibly human-readable) string describing the type of LAC or LNS 1953 being used. 1955 The Attribute Value field for this AVP has the following format: 1957 0 1 2 3 1958 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 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 | Vendor Name ... (arbitrary number of octets) 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 The Vendor Name is the indicated number of octets representing the 1964 vendor string. Human-readable text for this AVP MUST be provided in 1965 the US-ASCII charset [RFC1958, RFC2277]. 1967 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 1968 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 1969 (before hiding) of this AVP is 6 plus the length of the Vendor Name. 1971 Assigned Control Connection ID (SCCRQ, SCCRP, StopCCN) 1973 The Assigned Control Connection ID AVP, Attribute Type AVP-TBA-3, 1974 contains the ID being assigned to this control connection by the 1975 sender. 1977 The Attribute Value field for this AVP has the following format: 1979 0 1 2 3 1980 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 1981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 | Assigned Control Connection ID | 1983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 The Assigned Control Connection ID is a 4-octet non-zero unsigned 1986 integer. 1988 The Assigned Control Connection ID AVP establishes the identifier 1989 used to multiplex and demultiplex multiple control connections 1990 between a pair of LCCEs. Once the Assigned Control Connection ID AVP 1991 has been received by an LCCE, the Control Connection ID specified in 1992 the AVP MUST be included in the Control Connection ID field of all 1993 control packets sent to the peer for the lifetime of the control 1994 connection. Before the Assigned Control Connection ID AVP is 1995 received from a peer, all control messages MUST be sent to that peer 1996 with a Control Connection ID value of 0 in the header. Because a 1997 Control Connection ID value of 0 is used in this special manner, the 1998 zero value MUST NOT be sent as an Assigned Control Connection ID 1999 value. 2001 Under certain circumstances, an LCCE may need to send a StopCCN to a 2002 peer without having yet received an Assigned Control Connection ID 2003 AVP from the peer (i.e. SCCRQ sent, no SCCRP received yet). In this 2004 case, the Assigned Control Connection ID AVP that had been sent to 2005 the peer earlier (i.e. in the SCCRQ) MUST be sent as the Assigned 2006 Control Connection ID AVP in the StopCCN. This policy allows the 2007 peer to try to identify the appropriate control connection via a 2008 reverse lookup. 2010 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2011 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2012 (before hiding) of this AVP is 10. 2014 Receive Window Size (SCCRQ, SCCRP) 2016 The Receive Window Size AVP, Attribute Type 10, specifies the receive 2017 window size being offered to the remote peer. 2019 The Attribute Value field for this AVP has the following format: 2021 0 1 2022 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 | Window Size | 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 The Window Size is a 2-octet unsigned integer. 2028 If absent, the peer must assume a Window Size of 4 for its transmit 2029 window. 2031 The remote peer may send the specified number of control messages 2032 before it must wait for an acknowledgment. See Section 4.2 for more 2033 information on reliable control message delivery. 2035 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 2036 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2037 Length of this AVP is 8. 2039 Pseudowire Capabilities List (SCCRQ, SCCRP) 2041 The Pseudowire Capabilities List (PW Capabilities List) AVP, 2042 Attribute Type AVP-TBA-4, indicates the L2 payload types the sender 2043 can support. The specific payload type of a given session is 2044 identified by the Pseudowire Type AVP. 2046 The Attribute Value field for this AVP has the following format: 2048 0 1 2 3 2049 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 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 | PW Type 0 | ... | 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 | ... | PW Type N | 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 Defined PW types that may appear in this list are managed by IANA and 2057 will appear in associated pseudowire-specific documents for each PW 2058 type. 2060 If a sender includes a given PW type in the PW Capabilities List AVP, 2061 the sender assumes full responsibility for supporting that particular 2062 payload, such as any payload-specific AVPs, L2-Specific Sublayer, or 2063 control messages that may be defined in the appropriate companion 2064 document. 2066 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2067 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2068 (before hiding) of this AVP is 8 octets with one PW type specified, 2069 plus 2 octets for each additional PW type. 2071 Preferred Language (SCCRQ, SCCRP) 2073 The Preferred Language AVP, Attribute Type AVP-TBD-14, provides a 2074 method for an LCCE to indicate to the peer the language in which 2075 human-readable messages it sends SHOULD be composed. This AVP 2076 contains a single language tag or language range [RFC3066]. 2078 The Attribute Value field for this AVP has the following format: 2080 0 1 2 3 2081 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 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2083 | Preferred Language... (arbitrary number of octets) 2084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2086 The Preferred Language is the indicated number of octets representing 2087 the language tag or language range, encoded in the US-ASCII charset. 2089 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2090 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2091 (before hiding) of this AVP is 6 plus the length of the Preferred 2092 Language. 2094 5.4.4 Session Management AVPs 2096 Local Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI) 2098 The Local Session ID AVP (analogous to the Assigned Session ID in 2099 L2TPv2), Attribute Type AVP-TBA-5, contains the identifier being 2100 assigned to this session by the sender. 2102 The Attribute Value field for this AVP has the following format: 2104 0 1 2 3 2105 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 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 | Local Session ID | 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2110 The Local Session ID is a 4-octet non-zero unsigned integer. 2112 The Local Session ID AVP establishes the two identifiers used to 2113 multiplex and demultiplex sessions between two LCCEs. Each LCCE 2114 chooses any free value it desires, and sends it to the remote LCCE 2115 using this AVP. The remote LCCE MUST then send all data packets 2116 associated with this session using this value. Additionally, for all 2117 session-oriented control messages sent after this AVP is received 2118 (e.g. ICRP, ICCN, CDN, SLI, etc.), the remote LCCE MUST echo this 2119 value in the Remote Session ID AVP. 2121 Note that a Session ID value is unidirectional. Because each LCCE 2122 chooses its Session ID independent of its peer LCCE, the value does 2123 not have to match in each direction for a given session. 2125 See Section 4.1 for additional information about the Session ID. 2127 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2128 AVP SHOULD be 1 set to 1, but MAY vary (see Section 5.2). The Length 2129 (before hiding) of this AVP is 10. 2131 Remote Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI) 2133 The Remote Session ID AVP, Attribute Type AVP-TBA-6, contains the 2134 identifier that was assigned to this session by the peer. 2136 The Attribute Value field for this AVP has the following format: 2138 0 1 2 3 2139 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 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 | Remote Session ID | 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 The Remote Session ID is a 4-octet non-zero unsigned integer. 2146 The Remote Session ID AVP MUST be present in all session-level 2147 control messages. The AVP's value echoes the session identifier 2148 advertised by the peer via the Local Session ID AVP. It is the same 2149 value that will be used in all transmitted data messages by this side 2150 of the session. In most cases, this identifier is sufficient for the 2151 peer to look up session-level context for this control message. 2153 When a session-level control message must be sent to the peer before 2154 the Local Session ID AVP has been received, the value of the Remote 2155 Sesson ID AVP MUST be set to zero. Additionally, the Local Session 2156 ID AVP (sent in a previous control message for this session) MUST be 2157 included in the control message. The peer must then use the Local 2158 Session ID AVP to perform a reverse lookup to find its session 2159 context. Session-level control messages defined in this document 2160 that might be subject to a reverse lookup by a receiving peer include 2161 the CDN, WEN, and SLI. 2163 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2164 AVP SHOULD be set to 1, but MAY vary (see Section 5, but MAY vary 2165 (see Section 5.2). The Length (before hiding) of this AVP is 10. 2167 Assigned Cookie (ICRQ, ICRP, OCRQ, OCRP) 2169 The Assigned Cookie AVP, Attribute Type AVP-TBA-7, contains the 2170 Cookie value being assigned to this session by the sender. 2172 The Attribute Value field for this AVP has the following format: 2174 0 1 2 3 2175 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 2176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2177 | Assigned Cookie (32 or 64 bits) ... 2178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 The Assigned Cookie is a 4-octet or 8-octet random value. 2182 The Assigned Cookie AVP contains the value used to check the 2183 association of a received data message with the session identified by 2184 the Session ID. All data messages sent to a peer MUST use the 2185 Assigned Cookie sent by the peer in this AVP. The value's length (0, 2186 32, or 64 bits) is obtained by the Length of the AVP. 2188 A missing Assigned Cookie AVP or Assigned Cookie Value of zero length 2189 indicates that the Cookie field should not be present in any data 2190 packets sent to the LCCE sending this AVP. 2192 See Section 4.1 for additional information about the Assigned Cookie. 2194 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2195 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2196 (before hiding) of this AVP may be 6, 10, or 14 octets. 2198 Serial Number (ICRQ, OCRQ) 2200 The Serial Number AVP, Attribute Type 15, contains an identifier 2201 assigned by the LAC or LNS to this session. 2203 The Attribute Value field for this AVP has the following format: 2205 0 1 2 3 2206 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 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 | Serial Number | 2209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 The Serial Number is a 32-bit value. 2213 The Serial Number is intended to be an easy reference for 2214 administrators on both ends of a control connection to use when 2215 investigating session failure problems. Serial Numbers should be set 2216 to progressively increasing values, which are likely to be unique for 2217 a significant period of time across all interconnected LNSs and LACs. 2219 Note that in RFC 2661, this value was referred to as the "Call Serial 2220 Number AVP". It serves the same purpose and has the same attribute 2221 value and composition. 2223 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2224 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2225 (before hiding) of this AVP is 10. 2227 Remote End ID (ICRQ, OCRQ) 2229 The Remote End ID AVP, Attribute Type AVP-TBA-8, contains an 2230 identifier used to bind L2TP sessions to a given circuit, interface, 2231 or bridging instance. It also may be used to detect session-level 2232 ties. 2234 The Attribute Value field for this AVP has the following format: 2236 0 1 2 3 2237 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 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 | Remote End Identifier ... (arbitrary number of octets) 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 The Remote End Identifier field is a variable-length field whose 2243 value is unique for a given LCCE peer, as described in Section 3.3. 2245 A session-level tie is detected if an LCCE receives an ICRQ or OCRQ 2246 with an End ID AVP whose value matches that which was just sent in an 2247 outgoing ICRQ or OCRQ to the same peer. If the two values match, an 2248 LCCE recognizes that a tie exists (e.g. both LCCEs are attempting to 2249 establish sessions for the same circuit). The tie is broken by the 2250 Session Tie Breaker AVP. 2252 By default, the LAC-LAC cross-connect application (see section 2253 2.0(b)) of L2TP over an IP network MUST utilize the Router ID AVP and 2254 Remote End ID AVP to associate a circuit to an L2TP session. Other 2255 AVPs MAY be used for LCCE or circuit identification as specified in 2256 companion documents. 2258 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2259 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2260 (before hiding) of this AVP is 6 plus the length of the Remote End 2261 Identifier value. 2263 Application Code (ICRQ, OCRQ) 2265 The Application Code AVP, Attribute Type AVP-TBA-9, is a 2 octet 2266 value for enumerating application types for a given L2TP session. 2268 The Attribute Value field for this AVP has the following format: 2270 0 1 2271 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 | Application Code | 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 The Application Code is a 2 octet value used to identify a specific 2277 application for an L2TP session, perhaps causing certain values 2278 within AVPs defined in this document to be interpreted or acted upon 2279 in a different manner dictated by the Application Code. For example, 2280 a given Application Code could instruct an LCCE to perform a specific 2281 directory lookup on the Hostname and/or Router ID AVP information 2282 associated with this session (perhaps even encoding the destination 2283 address of the given directory server). 2285 An Application Code of 0, or absence of this AVP in any control 2286 message, indicates that all AVPs should be interpreted as defined in 2287 this document. 2289 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2290 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2291 (before hiding) of this AVP is 8. 2293 Session Tie Breaker (ICRQ, OCRQ) 2295 The Session Tie Breaker AVP, Attribute Type TBD, is used to break 2296 ties when two peers concurrently attempt to establish a session for 2297 the same circuit. 2299 The Attribute Value field for this AVP has the following format: 2301 0 1 2 3 2302 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 2303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2304 | Session Tie Breaker Value ... 2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2306 ... (64 bits) | 2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2309 The Session Tie Breaker Value is an 8-octet random value that is used 2310 to choose a session when two LCCEs concurrently request a session for 2311 the same circuit. A tie is detected by examining the peer's identity 2312 (described in Section 3.3) plus the per-session shared value 2313 communicated via the End ID AVP. In the case of a tie, the recipient 2314 of an ICRQ or OCRQ must compare the received tie breaker value with 2315 the one that it sent earlier. The LCCE with the lower value "wins", 2316 and the "loser" MUST send a CDN with result code set to RC-TBA-1 (as 2317 defined in Section 5.4.2) to tear down the session it instigated. In 2318 the case in which a tie is detected, tie breakers are sent by both 2319 sides, and the tie breaker values are equal, both sides MUST discard 2320 their sessions and restart session negotiation with new random tie 2321 breaker values. 2323 If a tie is detected but only one side sends a Session Tie Breaker 2324 AVP, the session initiator that included the Session Tie Breaker AVP 2325 "wins". If neither side issues a tie breaker, then both sides MUST 2326 tear down the session. 2328 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 2329 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2330 Length of this AVP is 14. 2332 Pseudowire Type (ICRQ, OCRQ) 2334 The Pseudowire Type (PW Type) AVP, Attribute Type AVP-TBA-10, 2335 indicates the L2 payload type of the packets that will be tunneled 2336 using this L2TP session. 2338 The Attribute Value field for this AVP has the following format: 2340 0 1 2341 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2343 | PW Type | 2344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 A peer MUST NOT request an incoming or outgoing call with a PW Type 2347 AVP specifying a value not advertised in the PW Capabilities List AVP 2348 it received during control connection establishment. Attempts to do 2349 so MUST result in the call being rejected via a CDN with the Result 2350 Code set to RC-TBA-2 (see Section 5.4.2). 2352 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2353 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2354 (before hiding) of this AVP is 8. 2356 L2-Specific Sublayer (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2358 The L2-Specific Sublayer AVP, Attribute Type AVP-TBA-11, indicates 2359 the the presence and format of the L2-Specific Sublayer the sender of 2360 this AVP requires on all incoming data packets for this L2TP session. 2362 0 1 2363 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2365 | L2-Specific Sublayer Type | 2366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2368 The L2-Specific Sublayer Type is a 2-octet unsigned integer with the 2369 following values defined in this document: 2371 0 - There is no L2-Specific Sublayer present. 2372 1 - The default L2-Specific Sublayer (defined in Section 4.6) 2373 is used. 2375 If this AVP is received and has a value other than zero, the 2376 receiving LCCE MUST include the identified L2-Specific Sublayer in 2377 its outgoing data messages. If the AVP is not received, it is 2378 assumed that there is no sublayer present. 2380 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2381 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2382 (before hiding) of this AVP is 8. 2384 Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2386 The Data Sequencing AVP, Attribute Type AVP-TBA-12, indicates that 2387 the sender requires some or all of the data packets that it receives 2388 to be sequenced. 2390 The Attribute Value field for this AVP has the following format: 2392 0 1 2393 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 | Data Sequencing Level | 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 The Data Sequencing Level is a 2-octet unsigned integer indicating 2399 the degree of incoming data traffic that the sender of this AVP 2400 wishes to be marked with sequence numbers. 2402 The following values are valid data sequencing levels: 2404 0 - No incoming data packets require sequencing. 2405 1 - Only non-IP data packets require sequencing. 2406 2 - All incoming data packets require sequencing. 2408 If a data sequencing level of 0 is specified, there is no need to 2409 send packets with sequence numbers. If sequence numbers are sent, 2410 they will be ignored upon receipt. If no Data Sequencing AVP is 2411 received, a data sequencing level of 0 is assumed. 2413 If a data sequencing level of 1 is specified, only non-IP traffic 2414 carried within the tunneled L2 frame should have sequence numbers 2415 applied. Non-IP traffic here refers to any packets that cannot be 2416 classified as an IP packet within their respective L2 framing (i.e., 2417 a PPP control packet or NETBIOS frame encapsulated by Frame Relay 2418 before being tunneled). All traffic that can be classified as IP MUST 2419 be sent with no sequencing (e.g. the S bit in the L2-Specific 2420 Sublayer is set to zero). If a packet is unable to be classified at 2421 all (e.g. due to it being compressed or encrypted at layer 2) or if 2422 an implementation is unable to perform such classification within L2 2423 frames, all packets MUST be provided with sequence numbers 2424 (essentially falling back to a data sequencing level of 2). 2426 If a data sequencing level of 2 is specified, all traffic MUST be 2427 sequenced. 2429 Data sequencing may only be requested when there is an L2-Specific 2430 Sublayer present that can provide sequence numbers. If sequencing is 2431 requested without requesting a L2-Specific Sublayer AVP, the session 2432 MUST be disconnected with a Result Code of RC-TBA-3. 2434 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2435 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2436 (before hiding) of this AVP is 6. 2438 Tx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2440 The Tx Connect Speed BPS AVP, Attribute Type 24, contains the speed 2441 of the facility chosen for the connection attempt. 2443 The Attribute Value field for this AVP has the following format: 2445 0 1 2 3 2446 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 2447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2448 | Tx Connect Speed BPS | 2449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2451 The Tx Connect Speed BPS is a 4-octet value indicating the speed in 2452 bits per second. A value of zero indicates that the speed is 2453 indeterminable or that there is no physical point-to-point link. 2455 When the optional Rx Connect Speed AVP is present, the value in this 2456 AVP represents the transmit connect speed from the perspective of the 2457 LAC (e.g. data flowing from the LAC to the remote system). When the 2458 optional Rx Connect Speed AVP is NOT present, the connection speed 2459 between the remote system and LAC is assumed to be symmetric and is 2460 represented by the single value in this AVP. 2462 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2463 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2464 (before hiding) of this AVP is 10. 2466 Rx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2468 The Rx Connect Speed AVP, Attribute Type 38, represents the speed of 2469 the connection from the perspective of the LAC (e.g. data flowing 2470 from the remote system to the LAC). 2472 The Attribute Value field for this AVP has the following format: 2474 0 1 2 3 2475 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 2476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 | Rx Connect Speed BPS | 2478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2480 Rx Connect Speed BPS is a 4-octet value indicating the speed in bits 2481 per second. A value of zero indicates that the speed is 2482 indeterminable or that there is no physical point-to-point link. 2484 Presence of this AVP implies that the connection speed may be 2485 asymmetric with respect to the transmit connect speed given in the Tx 2486 Connect Speed AVP. 2488 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2489 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2490 (before hiding) of this AVP is 10. 2492 Physical Channel ID (ICRQ, ICRP, OCRP) 2494 The Physical Channel ID AVP, Attribute Type 25, contains the vendor- 2495 specific physical channel number used for a call. 2497 The Attribute Value field for this AVP has the following format: 2499 0 1 2 3 2500 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 2501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2502 | Physical Channel ID | 2503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2505 Physical Channel ID is a 4-octet value intended to be used for 2506 logging purposes only. 2508 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2509 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2510 (before hiding) of this AVP is 10. 2512 5.4.5 Circuit Status AVPs 2514 Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI) 2516 The Circuit Status AVP, Attribute Type AVP-TBA-13, indicates the 2517 initial status of or a status change in the circuit to which the 2518 session is bound. 2520 The Attribute Value field for this AVP has the following format: 2522 0 1 2523 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 | Reserved |N|A| 2526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 The A (Active) bit indicates whether the circuit is up/active/ready 2529 (1) or down/inactive/not-ready (0). 2531 The N (New) bit indicates whether the circuit status indication is 2532 for a new circuit (1) or an existing circuit (0). Links which have a 2533 similar mechanism available (e.g. Frame Relay) MUST map the setting 2534 of this bit to the associated signaling for that link. Otherwise, the 2535 New bit SHOULD still be set the first time the L2TP session is 2536 established after provisioning. 2538 The remaining bits are reserved for future use. Reserved bits MUST 2539 be set to 0 when sending and ignored upon receipt. 2541 The Circuit Status AVP is used to advertise whether a circuit or 2542 interface bound to an L2TP session is up and ready to send and/or 2543 receive traffic. Different circuit types have different names for 2544 status types. For example, HDLC primary and secondary stations refer 2545 to a circuit as being "Receive Ready" or "Receive Not Ready", while 2546 Frame Relay refers to a circuit as "Active" or "Inactive". This AVP 2547 adopts the latter terminology, though the concept remains the same 2548 regardless of the PW type for the L2TP session. 2550 In the simplest case, the circuit referred by this AVP is a single 2551 physical interface, port, or circuit depending on application and how 2552 the session was setup. The status indication in this AVP may then be 2553 used to provide simple ILMI interworking for a variety of circuit 2554 types. For virtual or multipoint interfaces, the Circuit Status AVP 2555 is still utilized, but effectively refers to the state of an internal 2556 structure or a logical set of circuits. Each PW-specific companion 2557 document MUST then specify precisely how this AVP is translated for 2558 each circuit type. 2560 If this AVP is received with a Not Active notification for a given 2561 L2TP session, all data traffic for that session MUST cease (or not 2562 begin) in the direction of the sender of the Circuit Status AVP until 2563 the circuit is advertised as Active. 2565 The Circuit Status MUST be advertised by this AVP in ICRQ, ICRP, 2566 OCRQ, and OCRP messages. Often, the circuit type will be marked 2567 Active when initiated, but MAY be advertised as Inactive, indicating 2568 that an L2TP session is to be created but that the interface or 2569 circuit is still not ready to pass traffic. The ICCN, OCCN, and SLI 2570 control messages all MAY contain this AVP to update the status of the 2571 circuit after establishment of the L2TP session is requested. 2573 If additional circuit status information is needed for a given PW 2574 type, PW-specific AVPs MUST be defined in a separate document for 2575 that information. This AVP is only for general circuit status 2576 information applicable to all circuit/interface types. 2578 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2579 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2580 (before hiding) of this AVP is 8. 2582 Circuit Errors (WEN) 2584 The Circuit Errors AVP, Attribute Type 34, conveys circuit error 2585 information to the peer. 2587 The Attribute Value field for this AVP has the following format: 2589 0 1 2 3 2590 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 2591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2592 | Reserved | 2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2594 | Hardware Overruns | 2595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2596 | Buffer Overruns | 2597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2598 | Timeout Errors | 2599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2600 | Alignment Errors | 2601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2602 The following fields are defined: 2604 Reserved: 2 octets of Reserved data is present (providing longword 2605 alignment within the AVP of the following values). Reserved 2606 data MUST be zero on sending and ignored upon receipt. 2607 Hardware Overruns: Number of receive buffer overruns since call 2608 was established. 2609 Buffer Overruns: Number of buffer overruns detected since call was 2610 established. 2611 Timeout Errors: Number of timeouts since call was established. 2612 Alignment Errors: Number of alignment errors since call was 2613 established. 2615 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2616 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2617 (before hiding) of this AVP is 32. 2619 6. Control Connection Protocol Specification 2621 The following control messages are used to establish, maintain, and 2622 tear down L2TP control connections. All data packets are sent in 2623 network order (high-order octets first). Any "reserved" or "empty" 2624 fields MUST be sent as 0 values to allow for protocol extensibility. 2626 The exchanges in which these messages are involved are outlined in 2627 Section 3.3. 2629 6.1 Start-Control-Connection-Request (SCCRQ) 2631 Start-Control-Connection-Request (SCCRQ) is a control message used to 2632 initiate a control connection between two LCCEs. It is sent by 2633 either the LAC or the LNS to begin the control connection 2634 establishment process. 2636 The following AVPs MUST be present in the SCCRQ: 2638 Message Type 2639 Host Name 2640 Router ID 2641 Assigned Control Connection ID 2642 Pseudowire Capabilities List 2644 The following AVPs MAY be present in the SCCRQ: 2646 Random Vector 2647 Nonce 2648 Message Digest 2649 Control Connection Tie Breaker 2650 Vendor Name 2651 Receive Window Size 2652 Preferred Language 2654 6.2 Start-Control-Connection-Reply (SCCRP) 2656 Start-Control-Connection-Reply (SCCRP) is the control message sent in 2657 reply to a received SCCRQ message. The SCCRP is used to indicate 2658 that the SCCRQ was accepted and establishment of the control 2659 connection should continue. 2661 The following AVPs MUST be present in the SCCRP: 2663 Message Type 2664 Host Name 2665 Router ID 2666 Assigned Control Connection ID 2667 Pseudowire Capabilities List 2669 The following AVPs MAY be present in the SCCRP: 2671 Random Vector 2672 Nonce 2673 Message Digest 2674 Vendor Name 2675 Receive Window Size 2676 Preferred Language 2678 6.3 Start-Control-Connection-Connected (SCCCN) 2680 Start-Control-Connection-Connected (SCCCN) is the control message 2681 sent in reply to an SCCRP. The SCCCN completes the control 2682 connection establishment process. 2684 The following AVP MUST be present in the SCCCN: 2686 Message Type 2688 The following AVP MAY be present in the SCCCN: 2690 Random Vector 2691 Message Digest 2693 6.4 Stop-Control-Connection-Notification (StopCCN) 2695 Stop-Control-Connection-Notification (StopCCN) is the control message 2696 sent by either LCCE to inform its peer that the control connection is 2697 being shut down and that the control connection should be closed. In 2698 addition, all active sessions are implicitly cleared (without sending 2699 any explicit session control messages). The reason for issuing this 2700 request is indicated in the Result Code AVP. There is no explicit 2701 reply to the message, only the implicit ACK that is received by the 2702 reliable control message delivery layer. 2704 The following AVPs MUST be present in the StopCCN: 2706 Message Type 2707 Result Code 2709 The following AVPs MAY be present in the StopCCN: 2711 Random Vector 2712 Message Digest 2713 Assigned Control Connection ID 2715 Note that the Assigned Control Connection ID MUST be present if the 2716 StopCCN is sent after an SCCRQ or SCCRP message has been sent. 2718 6.5 Hello (HELLO) 2720 The Hello (HELLO) message is an L2TP control message sent by either 2721 peer of a control connection. This control message is used as a 2722 "keepalive" for the control connection. See Section 4.2 for a 2723 description of the keepalive mechanism. 2725 HELLO messages are global to the control connection. The Session ID 2726 in a HELLO message MUST be 0. 2728 The following AVP MUST be present in the HELLO: 2730 Message Type 2732 The following AVP MAY be present in the HELLO: 2734 Random Vector 2735 Message Digest 2737 6.6 Incoming-Call-Request (ICRQ) 2739 Incoming-Call-Request (ICRQ) is the control message sent by an LCCE 2740 to a peer when an incoming call is detected (although the ICRQ may 2741 also be sent as a result of a local event). It is the first in a 2742 three-message exchange used for establishing a session via an L2TP 2743 control connection. 2745 The ICRQ is used to indicate that a session is to be established 2746 between an LCCE and a peer. The sender of an ICRQ provides the peer 2747 with parameter information for the session. However, the sender 2748 makes no demands about how the session is terminated at the peer 2749 (i.e. whether the L2 traffic is processed locally, forwarded, etc.). 2751 The following AVPs MUST be present in the ICRQ: 2753 Message Type 2754 Local Session ID 2755 Remote Session ID 2756 Serial Number 2757 Pseudowire Type 2758 Circuit Status 2760 The following AVPs MAY be present in the ICRQ: 2762 Random Vector 2763 Message Digest 2764 Assigned Cookie 2765 Remote End ID 2766 Application ID 2767 Session Tie Breaker 2768 L2-Specific Sublayer 2769 Data Sequencing 2770 Tx Connect Speed 2771 Rx Connect Speed 2772 Physical Channel ID 2774 6.7 Incoming-Call-Reply (ICRP) 2776 Incoming-Call-Reply (ICRP) is the control message sent by an LCCE in 2777 response to a received ICRQ. It is the second in the three-message 2778 exchange used for establishing sessions within an L2TP control 2779 connection. 2781 The ICRP is used to indicate that the ICRQ was successful and that 2782 the peer should establish (i.e. answer) the incoming call if it has 2783 not already done so. It also allows the sender to indicate specific 2784 parameters about the L2TP session. 2786 The following AVPs MUST be present in the ICRP: 2788 Message Type 2789 Local Session ID 2790 Remote Session ID 2791 Circuit Status 2793 The following AVPs MAY be present in the ICRP: 2795 Random Vector 2796 Message Digest 2797 Assigned Cookie 2798 L2-Specific Sublayer 2799 Data Sequencing 2800 Tx Connect Speed 2801 Rx Connect Speed 2802 Physical Channel ID 2804 6.8 Incoming-Call-Connected (ICCN) 2806 Incoming-Call-Connected (ICCN) is the control message sent by the 2807 LCCE that originally sent an ICRQ upon receiving an ICRP from its 2808 peer. It is the final message in the three-message exchange used for 2809 establishing L2TP sessions. 2811 The ICCN is used to indicate that the ICRP was accepted, that the 2812 call has been established, and that the L2TP session should move to 2813 the established state. It also allows the sender to indicate 2814 specific parameters about the established call (parameters that may 2815 not have been available at the time the ICRQ is issued). 2817 The following AVPs MUST be present in the ICCN: 2819 Message Type 2820 Local Session ID 2821 Remote Session ID 2823 The following AVPs MAY be present in the ICCN: 2825 Random Vector 2826 Message Digest 2827 L2-Specific Sublayer 2828 Data Sequencing 2829 Tx Connect Speed 2830 Rx Connect Speed 2831 Circuit Status 2833 6.9 Outgoing-Call-Request (OCRQ) 2835 Outgoing-Call-Request (OCRQ) is the control message sent by an LCCE 2836 to an LAC to indicate that an outbound call at the LAC is to be 2837 established based on specific destination information sent in this 2838 message. It is the first in a three-message exchange used for 2839 establishing a session and placing a call on behalf of the initiating 2840 LCCE. 2842 Note that a call may be any L2 connection requiring well-known 2843 destination information to be sent from an LCCE to an LAC. This call 2844 could be a dialup connection to the PSTN, an SVC connection, the IP 2845 address of another LCCE, or any other destination dictated by the 2846 sender of this message. 2848 The following AVPs MUST be present in the OCRQ: 2850 Message Type 2851 Local Session ID 2852 Remote Session ID 2853 Serial Number 2854 Pseudowire Type 2855 Circuit Status 2857 The following AVPs MAY be present in the OCRQ: 2859 Random Vector 2860 Message Digest 2861 Assigned Cookie 2862 Remote End ID 2863 Application ID 2864 Tx Connect Speed 2865 Rx Connect Speed 2866 Session Tie Breaker 2867 L2-Specific Sublayer 2868 Data Sequencing 2870 6.10 Outgoing-Call-Reply (OCRP) 2872 Outgoing-Call-Reply (OCRP) is the control message sent by an LAC to 2873 an LCCE in response to a received OCRQ. It is the second in a three- 2874 message exchange used for establishing a session within an L2TP 2875 control connection. 2877 OCRP is used to indicate that the LAC has been able to attempt the 2878 outbound call. The message returns any relevant parameters regarding 2879 the call attempt. Data MUST NOT be forwarded until the OCCN is 2880 received indicating that the call has been placed. 2882 The following AVPs MUST be present in the OCRP: 2884 Message Type 2885 Local Session ID 2886 Remote Session ID 2887 Circuit Status 2889 The following AVPs MAY be present in the OCRP: 2891 Random Vector 2892 Message Digest 2893 Assigned Cookie 2894 L2-Specific Sublayer 2895 Tx Connect Speed 2896 Rx Connect Speed 2897 Data Sequencing 2898 Physical Channel ID 2900 6.11 Outgoing-Call-Connected (OCCN) 2902 Outgoing-Call-Connected (OCCN) is the control message sent by an LAC 2903 to another LCCE after the OCRP and after the outgoing call has been 2904 completed. It is the final message in a three-message exchange used 2905 for establishing a session. 2907 OCCN is used to indicate that the result of a requested outgoing call 2908 was successful. It also provides information to the LCCE who 2909 requested the call about the particular parameters obtained after the 2910 call was established. 2912 The following AVPs MUST be present in the OCCN: 2914 Message Type 2915 Local Session ID 2916 Remote Session ID 2918 The following AVPs MAY be present in the OCCN: 2920 Random Vector 2921 Message Digest 2922 L2-Specific Sublayer 2923 Tx Connect Speed 2924 Rx Connect Speed 2925 Data Sequencing 2926 Circuit Status 2928 6.12 Call-Disconnect-Notify (CDN) 2930 The Call-Disconnect-Notify (CDN) is a control message sent by an LCCE 2931 to request disconnection of a specific session. Its purpose is to 2932 inform the peer of the disconnection and the reason for the 2933 disconnection. The peer MUST clean up any resources, and does not 2934 send back any indication of success or failure for such cleanup. 2936 The following AVPs MUST be present in the CDN: 2938 Message Type 2939 Result Code 2940 Local Session ID 2941 Remote Session ID 2943 The following AVP MAY be present in the CDN: 2945 Random Vector 2946 Message Digest 2948 6.13 WAN-Error-Notify (WEN) 2950 The WAN-Error-Notify (WEN) is a control message sent from an LAC to an 2951 LNS to indicate WAN error conditions. The counters in this message 2952 are cumulative. This message should only be sent when an error 2953 occurs, and not more than once every 60 seconds. The counters are 2954 reset when a new call is established. 2956 The following AVPs MUST be present in the WEN: 2958 Message Type 2959 Local Session ID 2960 Remote Session ID 2961 Circuit Errors 2963 The following AVP MAY be present in the WEN: 2965 Random Vector 2966 Message Digest 2968 6.14 Set-Link-Info (SLI) 2970 The Set-Link-Info control message is sent by an LCCE to convey link 2971 or circuit status change information regarding the circuit associated 2972 with this L2TP session. For example, if PPP renegotiates LCP at an 2973 LNS or between an LAC and a Remote System, or if a forwarded Frame 2974 Relay VC transitions to Active or Inactive at an LAC, an SLI message 2975 SHOULD be sent to indicate this event. Precise details of when the 2976 SLI is sent, what PW type-specific AVPs must be present, and how 2977 those AVPs should be interpreted by the receiving peer are outside 2978 the scope of this document. These details should be described in the 2979 associated pseudowire-specific documents that require use of this 2980 message. 2982 The following AVPs MUST be present in the SLI: 2984 Message Type 2985 Local Session ID 2986 Remote Session ID 2988 The following AVPs MAY be present in the SLI: 2990 Random Vector 2991 Message Digest 2992 Circuit Status 2994 6.15 Explicit-Acknowledgement (ACK) 2996 The Explicit Acknowledgement (ACK) message is used only to 2997 acknowledge receipt of a message or messages on the Control 2998 Connection (e.g. for purposes of updating Ns and Nr values). Receipt 2999 of this message does not trigger an event for the L2TP protocol state 3000 machine. 3002 A message received without any AVPs (including the Message Type AVP), 3003 is referred to as a Zero Length Body (ZLB) message, and serves the 3004 same function as the Explicit Acknowledgement. ZLB messages are only 3005 permitted when the Control Message Authentication defined in Section 3006 4.3 is not enabled. 3008 The following AVPs MAY be present in the ACK message: 3010 Message Type 3011 Message Digest 3012 mi.sp 3013 7. Control Connection State Machines 3015 The state tables defined in this section govern the exchange of 3016 control messages defined in Section 6. Tables are defined for 3017 incoming call placement and outgoing call placement, as well as for 3018 initiation of the control connection itself. The state tables do not 3019 encode message timeout and retransmission behavior, as this is 3020 handled in the underlying reliable control message delivery mechanism 3021 (see Section 4.2). 3023 Timers MAY be employed to enforce a maximum period of time allowed in 3024 a transitional state (i.e. between idle and established). Generally, 3025 this is a protection mechanism for cleaning up state when an error 3026 has occurred, and should be treated as such. The precise period of 3027 time to wait is application dependent and MUST be configurable, with 3028 the notable default of no timeout at all. If a session is shutdown 3029 by a state transition timeout, a CDN MUST be sent with a Result Code 3030 set to RC-TBA-4 (see Section 5.4.2). If a control connection is 3031 shutdown by a state transition timeout, a StopCCN MUST be sent with a 3032 Result Code set to 7 (see Section 5.4.2). 3034 7.1 Malformed Control Messages 3036 Receipt of an invalid or unrecoverable malformed control message 3037 SHOULD be logged appropriately and the control connection cleared to 3038 ensure recovery to a known state. The control connection may then be 3039 restarted by the initiator. An invalid control message is defined as 3040 (1) a message that contains a Message Type marked as mandatory (see 3041 Section 5.4.1) but that is unknown to the implementation, or (2) a 3042 control message that is received in the wrong state. 3044 Examples of malformed control messages include (1) a message that has 3045 an invalid value in its header, (2) a message that contains an AVP 3046 that is formatted incorrectly or whose value is out of range, and (3) 3047 a message that is missing a required AVP. A control message with a 3048 malformed header MUST be discarded. 3050 If a malformed AVP is received with the M bit set, the session or 3051 control connection MUST be terminated with a proper Result or Error 3052 Code sent (see Section 5.2). A malformed yet non-mandatory (M bit is 3053 not set) AVP within a control message should be handled like an 3054 unrecognized non-mandatory AVP. That is, the AVP MUST be ignored 3055 (with the exception of logging a local error message), and the 3056 message MUST be accepted. 3058 It is impossible to list all potential malformations of a given 3059 message. However, an example of a recoverable, malformed AVP might 3060 be if the Rx Connect Speed AVP, attribute 38, is received with a 3061 length of 8 rather than 10, and the BPS given in 2 octets rather than 3062 4. In the Rx Connect Speed is sent with the M bit set to 0, this 3063 malformation should not be considered catastrophic. As such, the 3064 control message should be accepted as if the AVP had not been 3065 received (with the exception of a local error message being logged). 3066 This example is by no means a license to create malformed AVPs, but 3067 simply a guideline for how liberal one should be in acceptance of 3068 messages containing errors. 3070 In the following tables, there are several cases where a protocol 3071 message is sent and then a "clean up" occurs. Note that, regardless 3072 of the initiator of the control connection shutdown, the reliable 3073 delivery mechanism must be allowed to run (see Section 4.2) before 3074 destroying the control connection. This permits the control 3075 connection management messages to be reliably delivered to the peer. 3077 Appendix B.1 contains an example of lock-step control connection 3078 establishment. 3080 7.2 Control Connection States 3082 The L2TP control connection protocol is not distinguishable between 3083 the two LCCEs but is distinguishable between the originator and 3084 receiver. The originating peer is the one that first initiates 3085 establishment of the control connection. (In a tie breaker 3086 situation, this is the winner of the tie.) Since either the LAC or 3087 the LNS can be the originator, a collision can occur. See the 3088 Control Connection Tie Breaker AVP in Section 5.4.3 for a description 3089 of this and its resolution. 3091 State Event Action New State 3092 ----- ----- ------ --------- 3093 idle Local open Send SCCRQ wait-ctl-reply 3094 request 3096 idle Receive SCCRQ, Send SCCRP wait-ctl-conn 3097 acceptable 3099 idle Receive SCCRQ, Send StopCCN, idle 3100 not acceptable clean up 3102 idle Receive SCCRP Send StopCCN, idle 3103 clean up 3105 idle Receive SCCCN Send StopCCN, idle 3106 clean up 3107 wait-ctl-reply Receive SCCRP, Send SCCCN, established 3108 acceptable send control-conn 3109 open event to 3110 waiting sessions 3112 wait-ctl-reply Receive SCCRP, Send StopCCN, idle 3113 not acceptable clean up 3115 wait-ctl-reply Receive SCCRQ, Send SCCRP, wait-ctl-conn 3116 lose tie breaker, Clean up losing 3117 SCCRQ acceptable connection 3119 wait-ctl-reply Receive SCCRQ, Send StopCCN, idle 3120 lose tie breaker, Clean up losing 3121 SCCRQ unacceptable connection 3123 wait-ctl-reply Receive SCCRQ, Send StopCCN for wait-ctl-reply 3124 win tie breaker losing connection 3126 wait-ctl-reply Receive SCCCN Send StopCCN, idle 3127 clean up 3129 wait-ctl-conn Receive SCCCN, Send control-conn established 3130 acceptable open event to 3131 waiting sessions 3133 wait-ctl-conn Receive SCCCN, Send StopCCN, idle 3134 not acceptable clean up 3136 wait-ctl-conn Receive SCCRP, Send StopCCN, idle 3137 SCCRQ clean up 3139 established Local open Send control-conn established 3140 request open event to 3141 (new call) waiting sessions 3143 established Administrative Send StopCCN, idle 3144 control-conn clean up 3145 close event 3147 established Receive SCCRQ, Send StopCCN, idle 3148 SCCRP, SCCCN clean up 3150 idle, Receive StopCCN Clean up idle 3151 wait-ctl-reply, 3152 wait-ctl-conn, 3153 established 3155 The states associated with an LCCE for control connection 3156 establishment are as follows: 3158 idle 3159 Both initiator and recipient start from this state. An initiator 3160 transmits an SCCRQ, while a recipient remains in the idle state 3161 until receiving an SCCRQ. 3163 wait-ctl-reply 3164 The originator checks to see if another connection has been 3165 requested from the same peer, and if so, handles the collision 3166 situation described in Section 5.4.3. 3168 wait-ctl-conn 3169 Awaiting an SCCCN. Upon receipt, the challenge response contained 3170 in the message is checked. The control connection is established 3171 if authentication succeeds; otherwise, it is torn down. 3173 established 3174 An established connection may be terminated by either a local 3175 condition or the receipt of a StopCCN. In the event of a local 3176 termination, the originator MUST send a StopCCN and clean up the 3177 control connection. If the originator receives a StopCCN, it MUST 3178 also clean up the control connection. 3180 7.3 Incoming Calls 3182 An ICRQ is generated by an LCCE, typically in response to an incoming 3183 call or a local event. Once the LCCE sends the ICRQ, it waits for a 3184 response from the peer. However, it may choose to postpone 3185 establishment of the call (e.g. answering the call, bringing up the 3186 circuit) until the peer has indicated with an ICRP that it will 3187 accept the call. The peer may choose not to accept the call if, for 3188 instance, there are insufficient resources to handle an additional 3189 session. 3191 If the peer chooses to accept the call, it responds with an ICRP. 3192 When the local LCCE receives the ICRP, it attempts to establish the 3193 call. A final call connected message, the ICCN, is sent from the 3194 local LCCE to the peer to indicate that the call states for both 3195 LCCEs should enter the established state. If the call is terminated 3196 before the peer can accept it, a CDN is sent by the local LCCE to 3197 indicate this condition. 3199 When a call transitions to a "disconnected" or "down" state, the call 3200 is cleared normally, and the local LCCE sends a CDN. Similarly, if 3201 the peer wishes to clear a call, it sends a CDN and cleans up its 3202 session. 3204 7.3.1 ICRQ Sender States 3206 State Event Action New State 3207 ----- ----- ------ --------- 3209 idle Call signal or Initiate local wait-control-conn 3210 ready to receive control-conn 3211 incoming conn open 3213 idle Receive ICCN, Clean up idle 3214 ICRP, CDN 3216 wait-control- Bearer line drop Clean up idle 3217 conn or local close 3218 request 3220 wait-control- control-conn-open Send ICRQ wait-reply 3221 conn 3223 wait-reply Receive ICRP, Send ICCN established 3224 acceptable 3226 wait-reply Receive ICRP, Send CDN, idle 3227 Not acceptable clean up 3229 wait-reply Receive ICRQ Send CDN, idle 3230 clean up 3232 wait-reply Receive ICRQ, Process as idle 3233 lose tie breaker ICRQ Recipient 3234 (Section 7.3.2) 3236 wait-reply Receive ICRQ, Send CDN wait-reply 3237 win tie breaker for losing 3238 session 3240 wait-reply Receive CDN, Clean up idle 3241 ICCN 3243 wait-reply Local close Send CDN, idle 3244 request clean up 3246 established Receive CDN Clean up idle 3248 established Receive ICRQ, Send CDN, idle 3249 ICRP, ICCN clean up 3251 established Local close Send CDN, idle 3252 request clean up 3254 The states associated with the ICRQ sender are as follows: 3256 idle 3257 The LCCE detects an incoming call on one of its interfaces (e.g. 3258 an analog PSTN line rings, or an ATM PVC is provisioned), or a 3259 local event occurs. The LCCE initiates its control connection 3260 establishment state machine and moves to a state waiting for 3261 confirmation of the existence of a control connection. 3263 wait-control-conn 3264 In this state, the session is waiting for either the control 3265 connection to be opened or for verification that the control 3266 connection is already open. Once an indication that the control 3267 connection has been opened is received, session control messages 3268 may be exchanged. The first of these messages is the ICRQ. 3270 wait-reply 3271 The ICRQ sender receives either (1) a CDN indicating the peer is 3272 not willing to accept the call (general error or do not accept) 3273 and moves back into the idle state, or (2) an ICRP indicating the 3274 call is accepted. In the latter case, the LCCE sends an ICCN and 3275 enters the established state. 3277 established 3278 Data is exchanged over the session. The call may be cleared by 3279 any of the following: 3280 + An event on the connected interface: The LCCE sends a CDN. 3281 + Receipt of a CDN: The LCCE cleans up, disconnecting the call. 3282 + A local reason: The LCCE sends a CDN. 3284 7.3.2 ICRQ Recipient States 3286 State Event Action New State 3287 ----- ----- ------ --------- 3288 idle Receive ICRQ, Send ICRP wait-connect 3289 acceptable 3291 idle Receive ICRQ, Send CDN, idle 3292 not acceptable clean up 3294 idle Receive ICRP Send CDN idle 3295 clean up 3297 idle Receive ICCN Clean up idle 3299 wait-connect Receive ICCN Prepare for established 3300 acceptable data 3302 wait-connect Receive ICCN Send CDN, idle 3303 not acceptable clean up 3305 wait-connect Receive ICRQ, Send CDN, idle 3306 ICRP clean up 3308 idle, Receive CDN Clean up idle 3309 wait-connect, 3310 established 3312 wait-connect Local close Send CDN, idle 3313 established request clean up 3315 established Receive ICRQ, Send CDN, idle 3316 ICRP, ICCN clean up 3318 The states associated with the ICRQ recipient are as follows: 3320 idle 3321 An ICRQ is received. If the request is not acceptable, a CDN is 3322 sent back to the peer LCCE, and the local LCCE remains in the idle 3323 state. If the ICRQ is acceptable, an ICRP is sent. The session 3324 moves to the wait-connect state. 3326 wait-connect 3327 The local LCCE is waiting for an ICCN from the peer. Upon receipt 3328 of the ICCN, the local LCCE moves to established state. 3330 established 3331 The session is terminated either by sending a CDN or by receiving 3332 a CDN from the peer. Clean up follows on both sides regardless of 3333 the initiator. 3335 7.4 Outgoing Calls 3337 Outgoing calls instruct an LAC to place a call. There are three 3338 messages for outgoing calls: OCRQ, OCRP, and OCCN. An LCCE first 3339 sends an OCRQ to an LAC to request an outgoing call. The LAC MUST 3340 respond to the OCRQ with an OCRP once it determines that the proper 3341 facilities exist to place the call and that the call is 3342 administratively authorized. Once the outbound call is connected, 3343 the LAC sends an OCCN to the peer indicating the final result of the 3344 call attempt. 3346 7.4.1 OCRQ Sender States 3348 State Event Action New State 3349 ----- ----- ------ --------- 3350 idle Local open Initiate local wait-control-conn 3351 request control-conn-open 3353 idle Receive OCCN, Clean up idle 3354 OCRP 3356 wait-control- control-conn-open Send OCRQ wait-reply 3357 conn 3359 wait-reply Receive OCRP, none wait-connect 3360 acceptable 3362 wait-reply Receive OCRP, Send CDN, idle 3363 not acceptable clean up 3365 wait-reply Receive OCCN Send CDN, idle 3366 clean up 3368 wait-reply Receive ICRQ, Process as idle 3369 lose tie breaker OCRQ Recipient 3370 (Section 7.4.2) 3372 wait-reply Receive ICRQ, Send CDN wait-reply 3373 win tie breaker for losing 3374 session 3376 wait-connect Receive OCCN none established 3378 wait-connect Receive OCRQ, Send CDN, idle 3379 OCRP clean up 3381 idle, Receive CDN Clean up idle 3382 wait-reply, 3383 wait-connect, 3384 established 3386 established Receive OCRQ, Send CDN, idle 3387 OCRP, OCCN clean up 3389 wait-reply, Local close Send CDN, idle 3390 wait-connect, request clean up 3391 established 3393 wait-control- Local close Clean up idle 3394 conn request 3396 The states associated with the OCRQ sender are as follows: 3398 idle, wait-control-conn 3399 When an outgoing call request is initiated, a control connection 3400 is created as described above, if not already present. Once the 3401 control connection is established, an OCRQ is sent to the LAC, and 3402 the session moves into the wait-reply state. 3404 wait-reply 3405 If a CDN is received, the session is cleaned up and returns to 3406 idle state. If an OCRP is received, the call is in progress, and 3407 the session moves to the wait-connect state. 3409 wait-connect 3410 If a CDN is received, the session is cleaned up and returns to 3411 idle state. If an OCCN is received, the call has succeeded, and 3412 the session may now exchange data. 3414 established 3415 If a CDN is received, the session is cleaned up and returns to 3416 idle state. Alternatively, if the LCCE chooses to terminate the 3417 session, it sends a CDN to the LAC, cleans up the session, and 3418 moves the session to idle state. 3420 7.4.2 OCRQ Recipient (LAC) States 3422 State Event Action New State 3423 ----- ----- ------ --------- 3424 idle Receive OCRQ, Send OCRP, wait-cs-answer 3425 acceptable Place call 3427 idle Receive OCRQ, Send CDN, idle 3428 not acceptable clean up 3430 idle Receive OCRP Send CDN, idle 3431 clean up 3433 idle Receive OCCN, Clean up idle 3434 CDN 3436 wait-cs-answer Call placement Send OCCN established 3437 successful 3439 wait-cs-answer Call placement Send CDN, idle 3440 failed clean up 3442 wait-cs-answer Receive OCRQ, Send CDN, idle 3443 OCRP, OCCN clean up 3445 established Receive OCRQ, Send CDN, idle 3446 OCRP, OCCN clean up 3448 wait-cs-answer, Receive CDN Clean up idle 3449 established 3451 wait-cs-answer, Local close Send CDN, idle 3452 established request clean up 3454 The states associated with the LAC for outgoing calls are as follows: 3456 idle 3457 If the OCRQ is received in error, respond with a CDN. Otherwise, 3458 place the call, send an OCRP, and move to the wait-cs-answer 3459 state. 3461 wait-cs-answer 3462 If the call is not completed or a timer expires while waiting for 3463 the call to complete, send a CDN with the appropriate error 3464 condition set, and go to idle state. If a circuit-switched 3465 connection is established, send an OCCN indicating success, and go 3466 to established state. 3468 established 3469 If the LAC receives a CDN from the peer, the call MUST be released 3470 via appropriate mechanisms, and the session cleaned up. If the 3471 call is disconnected because the circuit transitions to a 3472 "disconnected" or "down" state, the LAC MUST send a CDN to the 3473 peer and return to idle state. 3475 7.5 Termination of a Control Connection 3477 The termination of a control connection consists of either peer 3478 issuing a StopCCN. The sender of this message SHOULD wait a full 3479 control message retransmission cycle (e.g. 1 + 2 + 4 + 8 ... seconds) 3480 for the acknowledgment of this message before releasing the control 3481 information associated with the control connection. The recipient of 3482 this message should send an acknowledgment of the message to the 3483 peer, then release the associated control information. 3485 When to release a control connection is an implementation issue and 3486 is not specified in this document. A particular implementation may 3487 use whatever policy is appropriate for determining when to release a 3488 control connection. Some implementations may leave a control 3489 connection open for a period of time or perhaps indefinitely after 3490 the last session for that control connection is cleared. Others may 3491 choose to disconnect the control connection immediately after the 3492 last call on the control connection disconnects. 3494 8. Security Considerations 3496 This section addresses some of the security issues that L2TP 3497 encounters in its operation. 3499 8.1 Control Connection Endpoint and Message Security 3501 The LCCEs may configure a shared secret (password) in order to 3502 perform a mutual authentication of one another, and construct an 3503 authentication and integrity check of all arriving Control Messages. 3504 This mechanism is built-in to L2TPv3, and is described in section 4.3 3505 and in the definition of the Message Digest and Nonce AVPs in section 3506 5.4.3. 3508 This mechanism provides strong mutual peer authentication, and 3509 authentication and integrity checking for individual Control 3510 Messages. 3512 8.2 Data Channel Security 3514 As described in section 4.1, the Assigned Cookie sent with each data 3515 packet MUST be selected in an unpredictable manner (with the added 3516 restriction that two same Cookie values not be selected within a 3517 short period of time for a given Session ID). 3519 A 64-bit Cookie provides effective protection against a blind packet 3520 insertion attack on a given PE. This is useful as a security feature 3521 only within networks where sniffing and correlating packets between 3522 L2TP nodes is considered impossible, though inserting IP packets 3523 destined to an LCCE may be considered possible (and perhaps trivial 3524 by an individual armed with the proper hacking tools). In such cases, 3525 the Cookie provides an effective barrier against packet insertion 3526 into a VPN by enforcing that a given Session ID match the random 64 3527 bit Cookie. A 32 bit Cookie is vulnerable to brute force guessing at 3528 high packet rates, and as such should not be considered an effective 3529 barrier to insertion attacks (it still provides an additional 3530 integrity check for the Session ID, as described in section 4.1). 3532 The L2TPv3 Cookie MUST NOT be regarded as a substitute for packet- 3533 level security such as that of IPsec when operating over an open or 3534 untrusted network where packets may be sniffed and values correlated 3535 to spoofed packets. L2TPv3 does not attempt to provide data packet 3536 encryption of any kind (without the aid of IPsec). 3538 8.3 End-to-End Security 3540 Protecting the L2TP packet stream with IPsec does, in turn, also 3541 protect the data within the tunneled session packets while 3542 transported from one LCCE to the other. Such protection MUST NOT be 3543 considered a substitution for end-to-end security between 3544 communicating hosts or applications. 3546 8.4 L2TP and IPsec 3548 When running over IP, IPsec [RFC2401] provides packet-level security 3549 via ESP [RFC3193]. All L2TP control and data packets for a 3550 particular control connection appear as homogeneous UDP or IP data 3551 packets to the IPsec system. 3553 In addition to IP transport security, IPsec defines a mode of 3554 operation that allows tunneling of IP packets. The packet-level 3555 encryption and authentication provided by IPsec tunnel mode and that 3556 provided by L2TP secured with IPsec provide an equivalent level of 3557 security for these requirements. 3559 IPsec also defines access control features that are required of a 3560 compliant IPsec implementation. These features allow filtering of 3561 packets based upon network and transport layer characteristics such 3562 as IP address, ports, etc. In the L2TP tunneling model, analogous 3563 filtering is logically performed at the network layer above L2TP. 3564 These network layer access control features may be handled at an LCCE 3565 via vendor-specific authorization features based upon the 3566 authenticated user, or at the network layer itself by using IPsec 3567 transport mode end-to-end between the communicating hosts. The 3568 requirements for access control mechanisms are not a part of the L2TP 3569 specification and as such are outside the scope of this document. 3571 8.5 Impact of L2TPv3 Features on RFC 3193 3573 [RFC3193] defines the recommended method for securing L2TPv2. L2TPv3 3574 possesses identical characteristics to IPsec as L2TPv2 when running 3575 on UDP/IP. When operating over IP directly, the principles defined 3576 in [RFC3193] still apply, though references to UDP port selection (in 3577 particular Section 4 "IPsec Filtering details when protecting L2TP") 3578 become far simpler as there are two less variable parameters (source 3579 and destination UDP ports) to be concerned with when applying 3580 filters. Specific details for operating L2TPv3 with IPsec will be 3581 specified in an update to [RFC3193]. 3583 9. Internationalization Considerations 3585 The Host Name and Vendor Name AVPs are not internationalized. The 3586 Vendor Name AVP, although intended to be human-readable, would seem 3587 to fit in the category of "globally visible names" [RFC3066] and so 3588 is represented in US-ASCII. 3590 The Preferred Language AVP is not mandatory. If an LCCE does not 3591 signify a language preference by the inclusion of this AVP in the 3592 SCCRQ or SCCRP, the Preferred Language AVP is unrecognized, or the 3593 requested language is not supported by the peer LCCE, the default 3594 language [RFC2277] MUST be used for all internationalized strings 3595 sent by the peer. 3597 10. IANA Considerations 3599 This document defines a number of "magic" numbers to be maintained by 3600 the IANA. This section explains the criteria to be used by the IANA 3601 to assign additional numbers in each of these lists. The following 3602 subsections describe the assignment policy for the namespaces defined 3603 elsewhere in this document. 3605 10.1 Control Message Attribute Value Pairs (AVPs) 3607 This number space is managed by IANA as per [RFC3438]. 3609 New AVPs requiring assignment in this document are defined in the 3610 "AVP Summary," Section 5.4, with the encoding "AVP-TBA-x," where "x" 3611 is 1, 2, 3... 3613 A summary of the new AVPs follows: 3615 AVP-TBA-1 Message Digest 3616 AVP-TBA-2 Router ID, 3617 AVP-TBA-3 Assigned Control Connection ID 3618 AVP-TBA-4 Pseudowire Capabilities List 3619 AVP-TBA-5 Local Session ID 3620 AVP-TBA-6 Remote Session ID 3621 AVP-TBA-7 Assigned Cookie 3622 AVP-TBA-8 Remote End ID 3623 AVP-TBA-9 Application Code 3624 AVP-TBA-10 Pseudowire Type 3625 AVP-TBA-11 L2-Specific Sublayer 3626 AVP-TBA-12 Data Sequencing 3627 AVP-TBA-13 Circuit Status 3628 AVP-TBA-14 Preferred Language 3629 AVP-TBA-15 Control Message Authentication Nonce 3631 10.2 Message Type AVP Values 3633 This number space is managed by IANA as per [RFC3438]. There is one 3634 new message type, defined in section 3.1, necessary to be allocated 3635 for this specification: 3636 TBA-M1 (ACK) Explicit Acknowledgement 3638 10.3 Result Code AVP Values 3640 This number space is managed by IANA as per [RFC3438]. 3642 New Result Code values for the CDN message are defined in section 3643 5.4. Following is a summary: 3645 RC-TBA-1 - Session not established due to losing tie breaker. 3646 RC-TBA-2 - Session not established due to unsupported PW type. 3647 RC-TBA-3 - Session not established, sequencing required without valid 3648 L2-Specific Sublayer. 3650 There are a few cases in Section 5 where these values are referred to 3651 directly within the document text with the RC-TBA-x format. The 3652 assigned values should be inserted within the text for these cases. 3654 10.3.2 Error Code Field Values 3656 This number space is managed by IANA as per [RFC3438]. 3658 10.4 AVP Header Bits 3660 There are four remaining reserved bits in the AVP header. Additional 3661 bits should only be assigned via a Standards Action [RFC2434]. 3663 10.5 L2TP Control Message Header Bits 3665 There are nine remaining reserved bits in the control message header. 3666 Additional bits should only be assigned via a Standards Action 3667 [RFC2434]. 3669 Care should be taken before using reserved bits 6 and 7 in the L2TPv3 3670 control message header since these bits have meaning for L2TPv2 data 3671 messages. Using these two bits in L2TPv3 MAY trigger an unforeseen 3672 interoperability problem with L2TPv3 implementations based on L2TPv2. 3673 Therefore, it is recommended that these two bits be utilized last, 3674 after the other reserved bits have been assigned roles. 3676 10.6 Pseudowire Types 3678 The Pseudowire Type (PW Type, Section 5.4) is a two-octet value used 3679 in the Pseudowire Type AVP and Pseudowire Capabilities List AVP 3680 defined in Section 5.4.3. 0 to 32767 are assignable by Expert Review 3681 [RFC2434], 32768 to 65535 by a First Come First Served policy 3682 [RFC2434]. There are no specific pseudowire types assigned within 3683 this document. Each pseudowire-specific document MUST allocate its 3684 own PW types from IANA as necessary. 3686 10.7 Application Code 3688 The Application Code (Section 5.4) is a two-octet value used in the 3689 Application Code AVP. Value 0 is assigned to the base application 3690 defined in this document. Additional Application Codes may be 3691 assigned by IETF Consensus [RFC2434]. 3693 10.8 Circuit Status Bits 3695 The Circuit Status (Section 5.4) field is a 16 bit mask, with the two 3696 high order bits assigned. 3698 Bit 15 - A (Active) bit 3699 Bit 16 - N (New) bit 3701 Additional bits may be assigned by IETF Consensus [RFC2434]. 3703 10.9 Default L2-Specific Sublayer bits 3705 The Default L2 Specific Sublayer defined in Section 4.6 contains 8 3706 bits in the low-order portion of the header, two of which have been 3707 assigned and 6 remain. 3709 Bit 0 - P (Priority) bit 3710 Bit 1 - S (Sequence) bit 3712 Additional values may be assigned by IETF Consensus [RFC2434]. 3714 10.10 L2-Specific Sublayer Type 3716 The L2-Specific Sublayer Type is a 2 octet unsigned integer of which 3717 two values have been assigned. 3719 0 - No L2-Specific Sublayer 3720 1 - Default L2-Specific Sublayer present 3722 Additional values may be assigned by Expert Review [RFC2434]. 3724 10.11 Data Sequencing Level 3726 The Data Sequencing Level is a 2 octet unsigned integer of which 3727 three values have been assigned. 3729 0 - No incoming data packets require sequencing. 3730 1 - Only non-IP data packets require sequencing. 3731 2 - All incoming data packets require sequencing. 3733 Additional values may be assigned by Expert Review [RFC2434]. 3735 13. Acknowledgments 3737 Many of the protocol constructs were originally defined in, and the 3738 text of this document began with, RFC 2661, "L2TPv2". RFC 2661 3739 authors are W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn and 3740 B. Palter. 3742 The basic concept for L2TP and many of its protocol constructs were 3743 adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these 3744 drafts are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, 3745 W. Verthein, J. Taarud, W. Little, and G. Zorn. 3747 Danny Mcpherson and Suhail Nanji published the first "L2TP Service 3748 Type" draft which defined the use of L2TP for tunneling of various L2 3749 payload types (initially, Ethernet and Frame Relay). 3751 The team for splitting RFC 2661 into this base document and the 3752 companion PPP document consisted of Ignacio Goyret, Jed Lau, Bill 3753 Palter, Mark Townsley, and Madhvi Verma. Skip Booth also provided 3754 very helpful review and comment. 3756 Some constructs of L2TPv3 were based in part on UTI (Universal 3757 Transport Interface), which was originally conceived by Peter 3758 Lothberg and Tony Bates. 3760 Stewart Bryant and Simon Barber provided valuable input for the 3761 L2TPv3 over IP header. 3763 Juha Heinanen provided helpful review, and input for the Application 3764 ID AVP. 3766 Jan Vilhuber, Scott Fluhrer, David McGrew, and Scott Wainner 3767 contributed to the Control Message and Authentication Mechanism as 3768 well as general discussions of security. 3770 James Carlson and Thomas Narten provided very helpful review. 3772 A number of people provided valuable input and effort for RFC2661, on 3773 which this document was based: 3775 John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, 3776 Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and 3777 review at the 43rd IETF in Orlando, FL, which led to improvement of 3778 the overall readability and clarity of RFC 2661. 3780 Thomas Narten provided a great deal of critical review and 3781 formatting. He wrote the first version of the IANA Considerations 3782 section. 3784 Dory Leifer made valuable refinements to the protocol definition of 3785 L2TP and contributed to the editing of early drafts leading to RFC 3786 2661. 3788 Steve Cobb and Evan Caves redesigned the state machine tables. 3790 Barney Wolff provided a great deal of design input on the endpoint 3791 authentication mechanism. 3793 11. References 3795 11.1 Normative References 3797 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 3798 RFC 1958, June 1996. 3800 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 3801 Protocol (CHAP)", RFC 1994, August 1996. 3803 [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, 3804 January 1997. 3806 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3807 Requirement Levels", BCP 14, RFC 2119, March 1997. 3809 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 3810 Languages", BCP 18, RFC 2277, January 1998. 3812 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3813 IANA Considerations section in RFCs", BCP 26, RFC 2434, 3814 October 1998. 3816 [RFC2661] Townsley, W., et al., "Layer Two Tunneling Layer Two Tunneling 3817 Protocol (L2TP)", RFC 2661, August 1999. 3819 [RFC2865] Rigney, C., Rubens, A., Simpson, W., and Willens, S., 3820 "Remote Authentication Dial In User Service (RADIUS)", 3821 RFC 2865, June 2000. 3823 [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", 3824 RFC 3066, January 2001. 3826 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and Booth, S., 3827 "Securing L2TP using IPsec", RFC 3193, November 2001. 3829 11.2 Informative References 3831 [KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network 3832 Security: Private Communications in a Public World", 3833 Prentice Hall, March 1995, ISBN 0-13-061466-1. 3835 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 3836 STD 13, RFC 1034, November 1987. 3838 [RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, 3839 04/16/1992 3841 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 3842 RFC 1661, July 1994. 3844 [RFC1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, 3845 RFC 1700, October 1994. See also: 3846 http://www.iana.org/numbers.html. 3848 [RFC1750] D. Eastlake III, S. Crocker, J. Schiller, "Randomness 3849 Recommendations for Security", RFC 1750, December 1994 3851 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for 3852 Message Authentication", RFC 2104, February 1997 3854 [RFC2138] Rigney, C., Rubens, A., Simpson, W., and Willens, S., 3855 "Remote Authentication Dial In User Service (RADIUS)", 3856 RFC 2138, April 1997. 3858 [RFC2341] Valencia, A., Littlewood, M., and Kolar, T., 3859 "Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341, 3860 May 1998. 3862 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 3863 Internet Protocol", RFC 2401, November 1998. 3865 [RFC2581] Allman, M., Paxson, V., Stevens, W., "TCP Congestion 3866 Control", RFC 2581, April 1999 3868 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., 3869 and Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", 3870 RFC 2637, July 1999. 3872 [RFC2809] Aboba, B., and Zorn, G., "Implementation of L2TP Compulsory 3873 Tunneling via RADIUS", RFC 2809, April 2000. 3875 [RFC3070] Rawat, V., Tio, R., Nanji, S., and Verma, R., 3876 "Layer Two Tunneling Protocol (L2TP) over Frame Relay", 3877 RFC 3070, February 2001. 3879 [RFC3355] Singh, A., Turner, R., Tio, R., Nanji, S., "Layer Two 3880 Tunnelling Protocol (L2TP) Over ATM Adaptation 3881 Layer 5 (AAL5)", RFC 3355, August 2002 3883 [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I: The 3884 Protocols", Addison-Wesley Publishing Company, Inc., 3885 March 1996, ISBN 0-201-63346-9. 3887 12. Editors' Addresses 3889 Jed Lau 3890 cisco Systems 3891 170 W. Tasman Drive 3892 San Jose, CA 95134 3893 jedlau@cisco.com 3895 W. Mark Townsley 3896 cisco Systems 3897 mark@townsley.net 3899 Ignacio Goyret 3900 Lucent Technologies 3901 igoyret@lucent.com 3903 Appendix A: Control Slow Start and Congestion Avoidance 3905 Although each side has indicated the maximum size of its receive 3906 window, it is recommended that a slow start and congestion avoidance 3907 method be used to transmit control packets. The methods described 3908 here are based upon the TCP congestion avoidance algorithm as 3909 described in section 21.6 of TCP/IP Illustrated, Volume I, by W. 3910 Richard Stevens [STEVENS] (this algorithm is also described in 3911 [RFC2581]). 3913 Slow start and congestion avoidance make use of several variables. 3914 The congestion window (CWND) defines the number of packets a sender 3915 may send before waiting for an acknowledgment. The size of CWND 3916 expands and contracts as described below. Note, however, that CWND 3917 is never allowed to exceed the size of the advertised window obtained 3918 from the Receive Window AVP. (In the text below, it is assumed any 3919 increase will be limited by the Receive Window Size.) The variable 3920 SSTHRESH determines when the sender switches from slow start to 3921 congestion avoidance. Slow start is used while CWND is less than 3922 SSHTRESH. 3924 A sender starts out in the slow start phase. CWND is initialized to 3925 one packet, and SSHTRESH is initialized to the advertised window 3926 (obtained from the Receive Window AVP). The sender then transmits 3927 one packet and waits for its acknowledgment (either explicit or 3928 piggybacked). When the acknowledgment is received, the congestion 3929 window is incremented from one to two. During slow start, CWND is 3930 increased by one packet each time an ACK (explicit ACK message or 3931 piggybacked) is received. Increasing CWND by one on each ACK has the 3932 effect of doubling CWND with each round trip, resulting in an 3933 exponential increase. When the value of CWND reaches SSHTRESH, the 3934 slow start phase ends and the congestion avoidance phase begins. 3936 During congestion avoidance, CWND expands more slowly. Specifically, 3937 it increases by 1/CWND for every new ACK received. That is, CWND is 3938 increased by one packet after CWND new ACKs have been received. 3939 Window expansion during the congestion avoidance phase is effectively 3940 linear, with CWND increasing by one packet each round trip. 3942 When congestion occurs (indicated by the triggering of a 3943 retransmission) one-half of the CWND is saved in SSTHRESH, and CWND 3944 is set to one. The sender then reenters the slow start phase. 3946 Appendix B: Control Message Examples 3948 B.1: Lock-Step Control Connection Establishment 3950 In this example, an LCCE establishes a control connection, with the 3951 exchange involving each side alternating in sending messages. This 3952 example shows the final acknowledgment explicitly sent within an ACK 3953 message. An alternative would be to piggyback the acknowledgment 3954 within a message sent as a reply to the ICRQ or OCRQ that will likely 3955 follow from the side that initiated the control connection. 3957 LCCE A LCCE B 3958 ------ ------ 3959 SCCRQ -> 3960 Nr: 0, Ns: 0 3961 <- SCCRP 3962 Nr: 1, Ns: 0 3963 SCCCN -> 3964 Nr: 1, Ns: 1 3965 <- ACK 3966 Nr: 2, Ns: 1 3968 B.2: Lost Packet with Retransmission 3970 An existing control connection has a new session requested by LCCE A. 3971 The ICRP is lost and must be retransmitted by LCCE B. Note that loss 3972 of the ICRP has two effects: It not only keeps the upper level state 3973 machine from progressing, but also keeps LCCE A from seeing a timely 3974 lower level acknowledgment of its ICRQ. 3976 LCCE A LCCE B 3977 ------ ------ 3978 ICRQ -> 3979 Nr: 1, Ns: 2 3980 (packet lost) <- ICRP 3981 Nr: 3, Ns: 1 3983 (pause; LCCE A's timer started first, so fires first) 3985 ICRQ -> 3986 Nr: 1, Ns: 2 3988 (Realizing that it has already seen this packet, 3989 LCCE B discards the packet and sends an ACK message) 3991 <- ACK 3992 Nr: 3, Ns: 2 3994 (LCCE B's retransmit timer fires) 3996 <- ICRP 3997 Nr: 3, Ns: 1 3998 ICCN -> 3999 Nr: 2, Ns: 3 4001 <- ACK 4002 Nr: 4, Ns: 2 4004 Appendix C: Processing Sequence Numbers 4006 The Default L2-Specific Sublayer, defined in Section 4.6, provides a 4007 24-bit field for sequencing of data packets within an L2TP session. 4008 L2TP data packets are never retransmitted, so this sequence is used 4009 only to detect packet order, duplicate packets, or lost packets. 4011 The 24-bit Sequence Number field of the Default L2-Specific Sublayer 4012 contains a packet sequence number for the associated session. Each 4013 sequenced data packet that is sent must contain the sequence number, 4014 incremented by one, of the previous sequenced packet sent on a given 4015 L2TP session. Upon receipt, any packet with a sequence number equal 4016 to or greater than the current expected packet (the last received in- 4017 order packet plus one) should be considered "new" and accepted. All 4018 other packets are considered "old" or "duplicate" and discarded. 4019 Note that the 24-bit sequence number space includes zero as a valid 4020 sequence number (as such, it may be implemented with a masked 32-bit 4021 counter if desired). All new sessions MUST begin sending sequence 4022 numbers at zero. 4024 Larger or smaller sequence number fields are possible with L2TP if an 4025 alternative format to the Default L2-Specific Sublayer defined in 4026 this document is used. While 24 bits may be adequate in a number of 4027 circumstances, a larger sequence number space will be less 4028 susceptible to sequence number wrapping problems for very high 4029 session data rates across long dropout periods. The sequence number 4030 processing recommendations below should hold for any size sequence 4031 number field. 4033 When detecting whether a packet sequence number is "greater" or 4034 "less" than a given sequence number value, wrapping of the sequence 4035 number must be considered. This is typically accomplished by keeping 4036 a window of sequence numbers beyond the current expected sequence 4037 number for determination of whether a packet is "new" or not. The 4038 window may be sized based on the link speed and sequence number space 4039 and SHOULD be configurable with a default equal to one half the size 4040 of the available number space (e.g. 2^(n-1), where n is the number of 4041 bits available in the sequence number). 4043 Upon receipt, packets which exactly match the expected sequence 4044 number are processed immediately and the next expected sequence 4045 number incremented. Packets that fall within the window for new 4046 packets may either be processed immediately and the next expected 4047 sequence number updated to one plus that received in the new packet, 4048 or held for a very short period of time in hopes of receiving the 4049 missing packet(s). This 'very short period' should be configurable, 4050 with a default corresponding to a time lapse which is at least an 4051 order of magnitude less than the retransmission timeout periods of 4052 higher layer protocols such as TCP. 4054 For typical transient packet mis-orderings, dropping out-of-order 4055 packets alone should suffice and generally requires far less 4056 resources than actively reordering packets within L2TP. An exception 4057 is a case where a pair of packet fragments are persistently 4058 retransmitted and sent out-of-order. For example, if an IP packet has 4059 been fragmented into a very small packet followed by a very large 4060 packet before being tunneled by L2TP, it is possible (though 4061 admittedly wrong) that the two resulting L2TP packets may be 4062 consistently mis-ordered by the PSN in transit between L2TP nodes. If 4063 sequence numbers were being enforced at the receiving node without 4064 any buffering of out-of-order packets, then the fragmented IP packet 4065 may never reach its destination. It may be worth noting here that 4066 this condition is true for any tunneling mechanism of IP packets 4067 which include sequence number checking on receipt (i.e. GRE 4068 [RFC2890]). 4070 Utilization of a Data Sequencing Level (see Section 5.4.3) of 1 (only 4071 non-IP data packets require sequencing) allows IP data packets being 4072 tunneled by L2TP to not utilize sequence numbers, while utilizing 4073 sequence numbers and enforcing packet order for any remaining non-IP 4074 data packets. Depending on the requirements of the link-layer being 4075 tunneled, and the network data traversing the data-link, this is 4076 sufficient in many cases to enforce packet order on frames which 4077 require it (such as end-to-end data-link control messages), while not 4078 on IP packets which are known to be resilient to packet reordering. 4080 If a large number of packets (e.g. more than one new packet window) 4081 are dropped due to an extended outage, or loss of sequence number 4082 state on one side of the connection (perhaps as part of a forwarding 4083 plane reset or failover to a standby node), it is possible that a 4084 large number of packets will be sent in-order, but be wrongly 4085 detected by the peer as out-of-order. This can be generally 4086 characterized for a window size, w, sequence number space, s, and 4087 number of packets lost in transit between L2TP endpoints, p, as 4088 follows: 4090 If s > p > w, then an additional (s - p) packets that were otherwise 4091 received in-order, will be incorrectly classified as out-of-order and 4092 dropped. Thus, for a sequence number space, s = 128, window size, w = 4093 64, and number of lost packets, p = 70; 128 - 70 = 58 additional 4094 packets would be dropped after the outage until the sequence number 4095 wrapped back to the current expected next sequence number. 4097 To mitigate this additional packet loss, one MUST inspect the 4098 sequence numbers of packets dropped due to being classified as "old" 4099 and reset the expected sequence number accordingly. This may be 4100 accomplished by counting the number of "old" packets dropped that 4101 were in sequence among themselves and upon reaching a threshold, 4102 resetting the next expected sequence number to that seen in the 4103 arriving data packets. Packet timestamps may also be used as an 4104 indicator to reset the expected sequence number by detecting a period 4105 of time over which "old" packets have been received in-sequence. The 4106 ideal thresholds will vary depending on link speed, sequence number 4107 space, and link tolerance to out-of-order packets, and MUST be 4108 configurable. 4110 Appendix D: Intellectual Property Notice 4112 The IETF takes no position regarding the validity or scope of any 4113 intellectual property or other rights that might be claimed to 4114 pertain to the implementation or use of the technology described in 4115 this document or the extent to which any license under such rights 4116 might or might not be available; neither does it represent that it 4117 has made any effort to identify any such rights. Information on the 4118 IETF's procedures with respect to rights in standards-track and 4119 standards-related documentation can be found in BCP-11. Copies of 4120 claims of rights made available for publication and any assurances of 4121 licenses to be made available, or the result of an attempt made to 4122 obtain a general license or permission for the use of such 4123 proprietary rights by implementers or users of this specification can 4124 be obtained from the IETF Secretariat. 4126 The IETF invites any interested party to bring to its attention any 4127 copyrights, patents or patent applications, or other proprietary 4128 rights that may cover technology that may be required to practice 4129 this standard. Please address the information to the IETF Executive 4130 Director. 4132 The IETF has been notified of intellectual property rights claimed in 4133 regard to some or all of the specification contained in this 4134 document. For more information consult the online list of claimed 4135 rights. 4137 Appendix E: Full Copyright Statement 4139 Copyright (C) The Internet Society (2002). All Rights Reserved. 4141 This document and translations of it may be copied and furnished to 4142 others, and derivative works that comment on or otherwise explain it 4143 or assist in its implementation may be prepared, copied, published 4144 and distributed, in whole or in part, without restriction of any 4145 kind, provided that the above copyright notice and this paragraph are 4146 included on all such copies and derivative works. However, this 4147 document itself may not be modified in any way, such as by removing 4148 the copyright notice or references to the Internet Society or other 4149 Internet organizations, except as needed for the purpose of 4150 developing Internet standards in which case the procedures for 4151 copyrights defined in the Internet Standards process must be 4152 followed, or as required to translate it into languages other than 4153 English. 4155 The limited permissions granted above are perpetual and will not be 4156 revoked by the Internet Society or its successors or assigns. 4158 This document and the information contained herein is provided on an 4159 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4160 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4161 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4162 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4163 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.