idnits 2.17.1 draft-ietf-l2tpext-l2tp-base-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4339. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 4355), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 91 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 92 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 3244 has weird spacing: '...eptable conn...' == Line 3250 has weird spacing: '...CCN for wai...' == Line 3251 has weird spacing: '...breaker los...' == Line 3256 has weird spacing: '...ol-conn esta...' == Line 3266 has weird spacing: '...ol-conn esta...' == (5 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 (June 2004) is 7255 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: 'RFC2473' is mentioned on line 1029, but not defined == Missing Reference: 'RFC3438' is mentioned on line 3780, but not defined == Missing Reference: 'RFC2890' is mentioned on line 4275, but not defined == Unused Reference: 'RFC1994' is defined on line 3921, but no explicit reference was found in the text == Unused Reference: 'RFC2138' is defined on line 3983, but no explicit reference was found in the text ** 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 1981 (Obsoleted by RFC 8201) -- 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) -- Obsolete informational reference (is this intentional?): RFC 2732 (Obsoleted by RFC 3986) Summary: 9 errors (**), 0 flaws (~~), 15 warnings (==), 16 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 June 2004 10 Layer Two Tunneling Protocol (Version 3) 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt . 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html . 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document describes "version 3" of the Layer Two Tunneling 42 Protocol (L2TPv3). L2TPv3 defines the base control protocol and 43 encapsulation for tunneling multiple layer 2 connections between two 44 IP connected nodes. Additional documents detail the specifics for 45 each link-type being emulated. 47 Contents 49 Status of this Memo.......................................... 1 51 1. Introduction............................................. 4 52 1.1 Changes from RFC 2661................................ 5 53 1.2 Specification of Requirements........................ 5 54 1.3 Terminology.......................................... 5 56 2. Topology................................................. 9 58 3. Protocol Overview........................................ 10 59 3.1 Control Message Types................................ 11 60 3.2 L2TP Header Formats.................................. 12 61 3.2.1 L2TP Control Message Header..................... 12 62 3.2.2 L2TP Data Message............................... 13 63 3.3 Control Connection Management........................ 14 64 3.3.1 Control Connection Establishment................ 14 65 3.3.2 Control Connection Teardown..................... 15 66 3.4 Session Management................................... 15 67 3.4.1 Session Establishment for an Incoming Call...... 15 68 3.4.2 Session Establishment for an Outgoing Call...... 16 69 3.4.3 Session Teardown................................ 16 71 4. Protocol Operation....................................... 17 72 4.1 L2TP Over Specific Packet-Switched Networks (PSNs)... 17 73 4.1.1 L2TPv3 over IP.................................. 18 74 4.1.2 L2TP over UDP................................... 19 75 4.1.3 L2TP and IPsec................................... 21 76 4.1.4 IP Fragmentation Issues......................... 22 77 4.2 Reliable Delivery of Control Messages................ 23 78 4.3 Control Connection and Control Message Authentication 26 79 4.4 Keepalive (Hello).................................... 27 80 4.5 Forwarding Session Data Frames....................... 27 81 4.6 Default L2-Specific Sublayer......................... 28 82 4.6.1 Sequencing Data Packets......................... 29 83 4.7 L2TPv2/v3 Interoperability and Migration............. 29 84 4.7.1 L2TPv3 over IP.................................. 29 85 4.7.2 L2TPv3 over UDP................................. 30 86 4.7.3 Automatic L2TPv2 Fallback....................... 30 88 5. Control Message Attribute Value Pairs.................... 31 89 5.1 AVP Format........................................... 31 90 5.2 Mandatory AVPs and Setting the M Bit................. 33 91 5.3 Hiding of AVP Attribute Values....................... 34 92 5.4 AVP Summary.......................................... 36 93 5.4.1 General Control Message AVPs.................... 36 94 5.4.2 Result and Error Codes.......................... 41 95 5.4.3 Control Connection Management AVPs.............. 43 96 5.4.4 Session Management AVPs......................... 48 97 5.4.5 Circuit Status AVPs............................. 56 99 6. Control Connection Protocol Specification................ 59 100 6.1 Start-Control-Connection-Request (SCCRQ)............. 59 101 6.2 Start-Control-Connection-Reply (SCCRP)............... 59 102 6.3 Start-Control-Connection-Connected (SCCCN)........... 60 103 6.4 Stop-Control-Connection-Notification (StopCCN)....... 60 104 6.5 Hello (HELLO)........................................ 61 105 6.6 Incoming-Call-Request (ICRQ)......................... 61 106 6.7 Incoming-Call-Reply (ICRP)........................... 62 107 6.8 Incoming-Call-Connected (ICCN)....................... 62 108 6.9 Outgoing-Call-Request (OCRQ)......................... 63 109 6.10 Outgoing-Call-Reply (OCRP).......................... 64 110 6.11 Outgoing-Call-Connected (OCCN)...................... 64 111 6.12 Call-Disconnect-Notify (CDN)........................ 65 112 6.13 WAN-Error-Notify (WEN).............................. 65 113 6.14 Set-Link-Info (SLI)................................. 66 114 6.15 Explicit-Acknowledgement (ACK)...................... 66 116 7. Control Connection State Machines........................ 67 117 7.1 Malformed AVPs and Control Messages.................. 67 118 7.2 Control Connection States............................ 68 119 7.3 Incoming Calls....................................... 70 120 7.3.1 ICRQ Sender States.............................. 71 121 7.3.2 ICRQ Recipient States........................... 72 122 7.4 Outgoing Calls....................................... 73 123 7.4.1 OCRQ Sender States.............................. 74 124 7.4.2 OCRQ Recipient (LAC) States..................... 75 125 7.5 Termination of a Control Connection.................. 76 127 8. Security Considerations.................................. 77 128 8.1 Control Connection Endpoint and Message Security..... 77 129 8.2 Data Packet Spoofing................................. 77 131 9. Internationalization Considerations...................... 78 133 10. IANA Considerations..................................... 79 134 10.1 Control Message Attribute Value Pairs (AVPs)........ 79 135 10.2 Message Type AVP Values............................. 80 136 10.3 Result Code AVP Values.............................. 80 137 10.4 AVP Header Bits..................................... 81 138 10.5 L2TP Control Message Header Bits.................... 81 139 10.6 Pseudowire Types..................................... 81 140 10.7 Circuit Status Bits.................................. 82 141 10.8 Default L2-Specific Sublayer bits.................... 82 142 10.9 L2-Specific Sublayer Type............................ 82 143 10.10 Data Sequencing Level............................... 83 145 11. References.............................................. 83 146 11.1 Normative References................................ 83 147 11.2 Informative References.............................. 84 149 12. Editors' Addresses...................................... 85 151 13. Acknowledgments......................................... 86 153 Appendix A: Control Slow Start and Congestion Avoidance...... 87 155 Appendix B: Control Message Examples......................... 88 157 Appendix C: Processing Sequence Numbers...................... 89 159 1. Introduction 161 The Layer Two Tunneling Protocol (L2TP) provides a dynamic mechanism 162 for tunneling Layer 2 (L2) "circuits" across a packet-oriented data 163 network (e.g., over IP). L2TP, as originally defined in RFC 2661, is 164 a standard method for tunneling Point to Point Protocol (PPP) 165 [RFC1661] sessions. L2TP has since been adopted for tunneling a 166 number of other L2 protocols. In order to provide greater 167 modularity, this document describes the base L2TP protocol, 168 independent of the L2 payload that is being tunneled. 170 The base L2TP protocol defined in this document consists of (1) the 171 control protocol for dynamic creation, maintenance, and teardown of 172 L2TP sessions, and (2) the L2TP data encapsulation to multiplex and 173 demultiplex L2 data streams between two L2TP nodes across an IP 174 network. Additional documents are expected to be published for each 175 layer 2 data link emulation type (a.k.a. pseudowire-type) supported 176 by L2TP (i.e., PPP, Ethernet, Frame Relay, etc.). These documents 177 will contain any individual details that are outside the scope of 178 this base specification. 180 When the designation between L2TPv2 and L2TPv3 is necessary, L2TP as 181 defined in RFC 2661 will be referred to as "L2TPv2", corresponding to 182 the value in the Version field of an L2TP header. (Layer 2 183 Forwarding, L2F, [RFC2341] was defined as "version 1".) At times, 184 L2TP as defined in this document will be referred to as "L2TPv3". 185 Otherwise, the acronym "L2TP" will refer to L2TPv3 or L2TP in 186 general. 188 1.1 Changes from RFC 2661 190 Many of the protocol constructs described in this document are 191 carried over from RFC 2661. Changes include clarifications based on 192 years of interoperability and deployment experience as well as 193 modifications to either improve protocol operation or provide a 194 clearer separation from PPP. The intent of these modifications is to 195 achieve a healthy balance between code reuse, interoperability 196 experience, and a directed evolution of L2TP as it is applied to new 197 tasks. 199 Notable differences between L2TPv2 and L2TPv3 include: 201 Separation of all PPP-related AVPs, references, etc., including a 202 portion of the L2TP data header that was specific to the needs of 203 PPP. The PPP-specific constructs are described in a companion 204 document. 206 Transition from a 16-bit Session ID and Tunnel ID to a 32-bit 207 Session ID and Control Connection ID, respectively. 209 Extension of the Tunnel Authentication mechanism to cover the 210 entire control message rather than just a portion of certain 211 messages. 213 Details of these changes and a recommendation for transitioning to 214 L2TPv3 are discussed in Section 4.7. 216 1.2 Specification of Requirements 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in [RFC2119]. 222 1.3 Terminology 224 Attribute Value Pair (AVP) 226 The variable-length concatenation of a unique Attribute 227 (represented by an integer), a length field, and a Value 228 containing the actual value identified by the attribute. Zero or 229 more AVPs make up the body of control messages, which are used in 230 the establishment, maintenance, and teardown of control 231 connections. This basic construct is sometimes referred to as a 232 Type-Length-Value (TLV) in some specifications. (See also: 233 Control Connection, Control Message.) 235 Call (Circuit Up) 237 The action of transitioning a circuit on an L2TP Access 238 Concentrator (LAC) to an "up" or "active" state. A call may be 239 dynamically established through signaling properties (e.g., an 240 incoming or outgoing call through the Public Switched Telephone 241 Network (PSTN)) or statically configured (e.g., provisioning a 242 Virtual Circuit on an interface). A call is defined by its 243 properties (e.g., type of call, called number, etc.) and its data 244 traffic. (See also: Circuit, Session, Incoming Call, Outgoing 245 Call, Outgoing Call Request.) 247 Circuit 249 A general term identifying any one of a wide range of L2 250 connections. A circuit may be virtual in nature (e.g., an ATM 251 PVC, an IEEE 802 VLAN, or an L2TP session), or it may have direct 252 correlation to a physical layer (e.g., an RS-232 serial line). 253 Circuits may be statically configured with a relatively long-lived 254 uptime, or dynamically established with signaling to govern the 255 establishment, maintenance, and teardown of the circuit. For the 256 purposes of this document, a statically configured circuit is 257 considered to be essentially the same as a very simple, long- 258 lived, dynamic circuit. (See also: Call, Remote System.) 260 Client 262 (See Remote System.) 264 Control Connection 266 An L2TP control connection is a reliable control channel that is 267 used to establish, maintain, and release individual L2TP sessions 268 as well as the control connection itself. (See also: Control 269 Message, Data Channel.) 271 Control Message 273 An L2TP message used by the control connection. (See also: 274 Control Connection.) 276 Data Message 278 Message used by the data channel. (a.k.a. Data Packet, See also: 279 Data Channel.) 281 Data Channel 283 The channel for L2TP-encapsulated data traffic that passes between 284 two LCCEs over a Packet Switched Network (i.e. IP). (See also: 285 Control Connection, Data Message.) 287 Incoming Call 289 The action of receiving a call (circuit up event) on an LAC. The 290 call may have been placed by a remote system (e.g., a phone call 291 over a PSTN), or it may have been triggered by a local event 292 (e.g., interesting traffic routed to a virtual interface). An 293 incoming call that needs to be tunneled (as determined by the LAC) 294 results in the generation of an L2TP ICRQ message. (See also: 295 Call, Outgoing Call, Outgoing Call Request.) 297 L2TP Access Concentrator (LAC) 299 If an L2TP Control Connection Endpoint (LCCE) is being used to 300 cross-connect an L2TP session directly to a data link, we refer to 301 it as an L2TP Access Concentrator (LAC). An LCCE may act as both 302 an L2TP Network Server (LNS) for some sessions and an LAC for 303 others, so these terms must only be used within the context of a 304 given set of sessions unless the LCCE is in fact single purpose 305 for a given topology. (See also: LCCE, LNS.) 307 L2TP Control Connection Endpoint (LCCE) 309 An L2TP node which exists at either end of an L2TP control 310 connection. May also be referred to as an LAC or LNS, depending on 311 whether tunneled frames are processed at the data link (LAC) or 312 network layer (LNS). (See also: LAC, LNS.) 314 L2TP Network Server (LNS) 316 If a given L2TP session is terminated at the L2TP node and the 317 encapsulated network layer (L3) packet processed on a virtual 318 interface, we refer to this L2TP node as an L2TP Network Server 319 (LNS). A given LCCE may act as both an LNS for some sessions and 320 an LAC for others, so these terms must only be used within the 321 context of a given set of sessions unless the LCCE is in fact 322 single purpose for a given topology. (See also: LCCE, LAC.) 324 Outgoing Call 326 The action of placing a call by an LAC, typically in response to 327 policy directed by the peer in an Outgoing Call Request message. 328 (See also: Call, Incoming Call, Outgoing Call Request.) 330 Outgoing Call Request 332 A request sent to an LAC to place an outgoing call. The request 333 contains specific information not known a priori by the LAC (i.e., 334 a number to dial). (See also: Call, Incoming Call, Outgoing 335 Call.) 337 Packet-Switched Network (PSN) 339 A network that uses packet-switching technology for data delivery. 340 For L2TPv3, this layer is principally IP. Other examples include 341 MPLS, Frame Relay, and ATM. 343 Peer 345 When used in context with L2TP, Peer refers to the far end of an 346 L2TP control connection (i.e., the remote LCCE). An LAC's peer 347 may be either an LNS or another LAC. Similarly, an LNS's peer may 348 be either an LAC or another LNS. (See also: LAC, LCCE, LNS.) 350 Pseudowire (PW) 352 An emulated circuit as it traverses a PSN. There is one 353 Pseudowire per L2TP Session. (See also: Packet-Switched Network, 354 Session.) 356 Pseudowire Type 358 The payload type being carried within an L2TP session. Examples 359 include PPP, Ethernet, and Frame Relay. (See also: Session.) 361 Remote System 363 An end-system or router connected by a circuit to an LAC. 365 Session 367 An L2TP session is the entity which is created between two LCCEs 368 in order to exchange parameters for and maintain an emulated L2 369 connection. Multiple sessions may be associated with a single 370 Control Connection. 372 Zero-Length Body (ZLB) Message 374 A control message with only an L2TP header. ZLB messages are used 375 only to acknowledge messages on the L2TP reliable control channel. 376 (See also: Control Message.) 378 2. Topology 380 L2TP operates between two L2TP Control Connection Endpoints (LCCEs), 381 tunneling traffic across a packet network. There are three 382 predominant tunneling models in which L2TP operates: LAC-LNS (or vice 383 versa), LAC-LAC, and LNS-LNS. These models are diagrammed below. 384 (Dotted lines designate network connections. Solid lines designate 385 circuit connections.) 387 Figure 2.0: L2TP Reference Models 389 (a) LAC-LNS Reference Model: On one side, the LAC receives traffic 390 from an L2 circuit, which it forwards via L2TP across an IP or other 391 packet-based network. On the other side, an LNS logically terminates 392 the L2 circuit locally and routes network traffic to the home 393 network. The action of session establishment is driven by the LAC 394 (as an incoming call) or the LNS (as an outgoing call). 396 +-----+ L2 +-----+ +-----+ 397 | |------| LAC |.........[ IP ].........| LNS |...[home network] 398 +-----+ +-----+ +-----+ 399 remote 400 system 401 |<-- emulated service -->| 402 |<----------- L2 service ------------>| 404 (b) LAC-LAC Reference Model: In this model, both LCCEs are LACs. 405 Each LAC forwards circuit traffic from the remote system to the peer 406 LAC using L2TP, and vice versa. In its simplest form, an LAC acts as 407 a simple cross-connect between a circuit to a remote system and an 408 L2TP session. This model typically involves symmetric establishment; 409 that is, either side of the connection may initiate a session at any 410 time (or simultaneously, in which a tie-breaking mechanism is 411 utilized). 413 +-----+ L2 +-----+ +-----+ L2 +-----+ 414 | |------| LAC |........[ IP ]........| LAC |------| | 415 +-----+ +-----+ +-----+ +-----+ 416 remote remote 417 system system 418 |<- emulated service ->| 419 |<----------------- L2 service ----------------->| 421 (c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs. A 422 user-level, traffic-generated, or signaled event typically drives 423 session establishment from one side of the tunnel. For example, a 424 tunnel generated from a PC by a user, or automatically by customer 425 premises equipment. 427 +-----+ +-----+ 428 [home network]...| LNS |........[ IP ]........| LNS |...[home network] 429 +-----+ +-----+ 430 |<- emulated service ->| 431 |<---- L2 service ---->| 433 Note: In L2TPv2, user-driven tunneling of this type is often referred 434 to as "voluntary tunneling" [RFC2809]. Further, an LNS acting as part 435 of a software package on a host is sometimes referred to as an "LAC 436 Client" [RFC2661]. 438 3. Protocol Overview 440 L2TP is comprised of two types of messages, control messages and data 441 messages (sometimes referred to as "control packets" and "data 442 packets", respectively). Control messages are used in the 443 establishment, maintenance, and clearing of control connections and 444 sessions. These messages utilize a reliable control channel within 445 L2TP to guarantee delivery (see Section 4.2 for details). Data 446 messages are used to encapsulate the L2 traffic being carried over 447 the L2TP session. Unlike control messages, data messages are not 448 retransmitted when packet loss occurs. 450 The L2TPv3 control message format defined in this document borrows 451 largely from L2TPv2. These control messages are used in conjunction 452 with the associated protocol state machines that govern the dynamic 453 setup, maintenance, and teardown for L2TP sessions. The data message 454 format for tunneling data packets may be utilized with or without the 455 L2TP control channel, either via manual configuration or other 456 signaling methods to pre-configure or distribute L2TP session 457 information. Utilization of the L2TP data message format with other 458 signaling methods is outside the scope of this document. 460 Figure 3.0: L2TPv3 Structure 462 +-------------------+ +-----------------------+ 463 | Tunneled Frame | | L2TP Control Message | 464 +-------------------+ +-----------------------+ 465 | L2TP Data Header | | L2TP Control Header | 466 +-------------------+ +-----------------------+ 467 | L2TP Data Channel | | L2TP Control Channel | 468 | (unreliable) | | (reliable) | 469 +-------------------+----+-----------------------+ 470 | Packet-Switched Network (IP, FR, MPLS, etc.) | 471 +------------------------------------------------+ 473 Figure 3.0 depicts the relationship of control messages and data 474 messages over the L2TP control and data channels, respectively. Data 475 messages are passed over an unreliable data channel, encapsulated by 476 an L2TP header, and sent over a Packet-Switched Network (PSN) such as 477 IP, UDP, Frame Relay, ATM, MPLS, etc. Control messages are sent over 478 a reliable L2TP control channel, which operates over the same PSN. 480 The necessary setup for tunneling a session with L2TP consists of two 481 steps: (1) Establishing the control connection, and (2) establishing 482 a session as triggered by an incoming call or outgoing call. An L2TP 483 session MUST be established before L2TP can begin to forward session 484 frames. Multiple sessions may be bound to a single control 485 connection, and multiple control connections may exist between the 486 same two LCCEs. 488 3.1 Control Message Types 490 The Message Type AVP (see Section 5.4.1) defines the specific type of 491 control message being sent. 493 This document defines the following control message types (see 494 Sections 6.1 through 6.13 for details on the construction and use of 495 each message): 497 Control Connection Management 499 0 (reserved) 500 1 (SCCRQ) Start-Control-Connection-Request 501 2 (SCCRP) Start-Control-Connection-Reply 502 3 (SCCCN) Start-Control-Connection-Connected 503 4 (StopCCN) Stop-Control-Connection-Notification 504 5 (reserved) 505 6 (HELLO) Hello 506 TBA-M1 (ACK) Explicit Acknowledgement 508 Call Management 510 7 (OCRQ) Outgoing-Call-Request 511 8 (OCRP) Outgoing-Call-Reply 512 9 (OCCN) Outgoing-Call-Connected 513 10 (ICRQ) Incoming-Call-Request 514 11 (ICRP) Incoming-Call-Reply 515 12 (ICCN) Incoming-Call-Connected 516 13 (reserved) 517 14 (CDN) Call-Disconnect-Notify 519 Error Reporting 521 15 (WEN) WAN-Error-Notify 523 Link Status Change Reporting 525 16 (SLI) Set-Link-Info 527 3.2 L2TP Header Formats 529 This section defines header formats for L2TP control messages and 530 L2TP data messages. All values are placed into their respective 531 fields and sent in network order (high-order octets first). 533 3.2.1 L2TP Control Message Header 535 The L2TP control message header provides information for the reliable 536 transport of messages that govern the establishment, maintenance, and 537 teardown of L2TP sessions. By default, control messages are sent 538 over the underlying media in-band with L2TP data messages. 540 The L2TP control message header is formatted as follows: 542 Figure 3.2.1: L2TP Control Message Header 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 |T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Control Connection ID | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Ns | Nr | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 The T bit MUST be set to 1, indicating that this is a control 555 message. 557 The L and S bits MUST be set to 1, indicating that the Length field 558 and sequence numbers are present. 560 The x bits are reserved for future extensions. All reserved bits 561 MUST be set to 0 on outgoing messages and ignored on incoming 562 messages. 564 The Ver field indicates the version of the L2TP control message 565 header described in this document. On sending, this field MUST be 566 set to 3 for all messages (unless operating in an environment which 567 includes L2TPv2 [RFC2661] and/or L2F [RFC2341] as well, see Section 568 4.1 for details). 570 The Length field indicates the total length of the message in octets, 571 always calculated from the start of the control message header itself 572 (beginning with the T bit). 574 The Control Connection ID field contains the identifier for the 575 control connection. L2TP control connections are named by 576 identifiers that have local significance only. That is, the same 577 control connection will be given unique Control Connection IDs by 578 each LCCE from within each endpoint's own Control Connection ID 579 number space. As such, the Control Connection ID in each message is 580 that of the intended recipient, not the sender. Non-zero Control 581 Connection IDs are selected and exchanged as Assigned Control 582 Connection ID AVPs during the creation of a control connection. 584 Ns indicates the sequence number for this control message, beginning 585 at zero and incrementing by one (modulo 2**16) for each message sent. 586 See Section 4.2 for more information on using this field. 588 Nr indicates the sequence number expected in the next control message 589 to be received. Thus, Nr is set to the Ns of the last in-order 590 message received plus one (modulo 2**16). See Section 4.2 for more 591 information on using this field. 593 3.2.2 L2TP Data Message 595 In general, an L2TP data message consists of a (1) Session Header, 596 (2) an optional L2-Specific Sublayer, and (3) the Tunnel Payload, as 597 depicted below. 599 Figure 3.2.2: L2TP Data Message Header 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | L2TP Session Header | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | L2-Specific Sublayer | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Tunnel Payload ... 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 The L2TP Session Header is specific to the encapsulating PSN over 610 which the L2TP traffic is delivered. The Session Header MUST provide 611 (1) a method of distinguishing traffic among multiple L2TP data 612 sessions and (2) a method of distinguishing data messages from 613 control messages. 615 Each type of encapsulating PSN MUST define its own session header, 616 clearly identifying the format of the header and parameters necessary 617 to setup the session. Section 4.1 defines two session headers, one 618 for transport over UDP and one for transport over IP. 620 The L2 Specific Sublayer is an intermediary layer between the L2TP 621 session header and the start of the tunneled frame. It contains 622 control fields that are used to facilitate the tunneling of each 623 frame (e.g. sequence numbers or flags). The default L2-Specific 624 Sublayer for L2TPv3 is defined in Section 4.6. 626 The Data Message Header is followed by the Tunnel Payload, including 627 any necessary L2 framing as defined in the payload-specific companion 628 documents. 630 3.3 Control Connection Management 632 The L2TP Control Connection handles dynamic establishment, teardown, 633 and maintenance of the L2TP sessions and of the control connection 634 itself. The reliable delivery of control messages is described in 635 Section 4.2. 637 This section describes typical control connection establishment and 638 teardown exchanges. It is important to note that, in the diagrams 639 that follow, the reliable control message delivery mechanism exists 640 independently of the L2TP state machine. For instance, Explicit 641 Acknowledgement (ACK) messages may be sent after any of the control 642 messages indicated in the exchanges below if an acknowledgment is not 643 piggybacked on a later control message. 645 LCCEs are identified during control connection establishment either 646 by the Host Name AVP, the Router ID AVP, or a combination of the two 647 (see Section 5.4.3). The identity of a peer LCCE is central to 648 selecting proper configuration parameters (i.e. Hello interval, 649 window size, etc.) for a control connection, as well as for 650 determination of how to setup associated sessions within the control 651 connection, password lookup for control connection authentication, 652 control connection level tie-breaking, etc. 654 3.3.1 Control Connection Establishment 656 Establishment of the control connection involves an exchange of AVPs 657 that identifies the peer and its capabilities. 659 A three-message exchange is used to establish the control connection. 660 The following is a typical message exchange: 662 LCCE A LCCE B 663 ------ ------ 664 SCCRQ -> 665 <- SCCRP 666 SCCCN -> 668 3.3.2 Control Connection Teardown 670 Control connection teardown may be initiated by either LCCE and is 671 accomplished by sending a single StopCCN control message. As part of 672 the reliable control message delivery mechanism, the recipient of a 673 StopCCN MUST send an ACK message to acknowledge receipt of the 674 message and maintain enough control connection state to properly 675 accept StopCCN retransmissions over at least a full retransmission 676 cycle (in case the ACK message is lost). The recommended time for a 677 full retransmission cycle is at least 31 seconds (see Section 4.2). 678 The following is an example of a typical control message exchange: 680 LCCE A LCCE B 681 ------ ------ 682 StopCCN -> 683 (Clean up) 685 (Wait) 686 (Clean up) 688 An implementation may shut down an entire control connection and all 689 sessions associated with the control connection by sending the 690 StopCCN. Thus, it is not necessary to clear each session 691 individually when tearing down the whole control connection. 693 3.4 Session Management 695 After successful control connection establishment, individual 696 sessions may be created. Each session corresponds to a single data 697 stream between the two LCCEs. This section describes the typical 698 call establishment and teardown exchanges. 700 3.4.1 Session Establishment for an Incoming Call 702 A three-message exchange is used to establish the session. The 703 following is a typical sequence of events: 705 LCCE A LCCE B 706 ------ ------ 707 (Call 708 Detected) 710 ICRQ -> 711 <- ICRP 712 (Call 713 Accepted) 715 ICCN -> 717 3.4.2 Session Establishment for an Outgoing Call 719 A three-message exchange is used to set up the session. The 720 following is a typical sequence of events: 722 LCCE A LCCE B 723 ------ ------ 724 <- OCRQ 725 OCRP -> 727 (Perform 728 Call 729 Operation) 731 OCCN -> 733 (Call Operation 734 Completed 735 Successfully) 737 3.4.3 Session Teardown 739 Session teardown may be initiated by either the LAC or LNS and is 740 accomplished by sending a CDN control message. After the last 741 session is cleared, the control connection MAY be torn down as well 742 (and typically is). The following is an example of a typical control 743 message exchange: 745 LCCE A LCCE B 746 ------ ------ 747 CDN -> 748 (Clean up) 750 (Clean up) 752 4. Protocol Operation 754 4.1 L2TP Over Specific Packet-Switched Networks (PSNs) 756 L2TP may operate over a variety of Packet Switched Networks (PSNs). 757 There are two modes described for operation over IP, L2TP directly 758 over IP (Section 4.1.1) and L2TP over UDP (Section 4.1.2). L2TPv3 759 implementations MUST support L2TP over IP and SHOULD support L2TP 760 over UDP for better NAT and firewall traversal, and easier migration 761 from L2TPv2. 763 L2TP over other PSNs may be defined, but the specifics are outside 764 the scope of this document. Examples of L2TPv2 over other PSNs 765 include [RFC3070] and [RFC3355]. 767 The following field definitions are defined for use in all L2TP 768 Session Header encapsulations. 770 Session ID 772 A 32-bit field containing a non-zero identifier for a session. 773 L2TP sessions are named by identifiers that have local 774 significance only. That is, the same logical session will be 775 given different Session IDs by each end of the control connection 776 for the life of the session. When the L2TP control connection is 777 used for session establishment, Session IDs are selected and 778 exchanged as Local Session ID AVPs during the creation of a 779 session. The Session ID alone provides the necessary context for 780 all further packet processing, including the presence, size and 781 value of the Cookie, L2-Specific Sublayer, and the type of payload 782 being tunneled. 784 Cookie 786 The optional Cookie field contains a variable length (maximum 64 787 bits) value used to check the association of a received data 788 message with the session identified by the Session ID. The Cookie 789 MUST be set to the configured or signaled random value for this 790 session. The Cookie provides an additional level of guarantee 791 that a data message has been directed to the proper session by the 792 Session ID. A well-chosen Cookie may prevent inadvertent 793 misdirection of stray packets with recently reused Session IDs, 794 Session IDs subject to packet corruption, etc. The Cookie may 795 also provide protection against some specific malicious packet 796 insertion attacks, as described in section 8.2. 798 When the L2TP control connection is used for session 799 establishment, random Cookie values are selected and exchanged as 800 Assigned Cookie AVPs during session creation. 802 4.1.1 L2TPv3 over IP 804 L2TPv3 over IP (both versions) utilizes the IANA assigned IP protocol 805 ID 115. 807 4.1.1.1 L2TPv3 Session Header Over IP 809 Unlike L2TP over UDP, the L2TPv3 session header over IP is free of 810 any restrictions imposed by coexistence with L2TPv2 and L2F. As 811 such, the header format has been designed to optimize packet 812 processing. The following session header format is utilized when 813 operating L2TPv3 over IP: 815 Figure 4.1.1.1: L2TPv3 Session Header Over IP 817 0 1 2 3 818 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 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Session ID | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Cookie (optional, maximum 64 bits)... 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 The Session ID and Cookie fields are as defined in Section 4.1. The 828 Session ID of zero is reserved for use by L2TP control messages (see 829 Section 4.1.1.2). 831 4.1.1.2 L2TP Control and Data Traffic over IP 833 Unlike L2TP over UDP which uses the T bit to distinguish between L2TP 834 control and data packets, L2TP over IP uses the reserved Session ID 835 of zero (0) when sending control messages. It is presumed that 836 checking for the zero Session ID is more efficient -- both in header 837 size for data packets and in processing speed for distinguishing 838 between control and data messages -- than checking a single bit. 840 The entire control message header over IP, including the zero session 841 ID, appears as follows: 843 Figure 4.1.1.2: L2TPv3 Control Message Header Over IP 845 0 1 2 3 846 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 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | (32 bits of zeros) | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 |T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Control Connection ID | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Ns | Nr | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 Named fields are as defined in Section 3.2.1. Note that the Length 858 field is still calculated from the beginning of the control message 859 header, beginning with the T bit. It does NOT include the "(32 bits 860 of zeros)" depicted above. 862 When operating directly over IP, L2TP packets lose the ability to 863 take advantage of the UDP checksum as a simple packet integrity 864 check. This is of particular concern for L2TP control messages. 865 Control Message Authentication (Section 4.3), even with an empty 866 password field, provides for a sufficient packet integrity check and 867 SHOULD always be enabled. 869 4.1.2 L2TP over UDP 871 L2TPv3 over UDP must consider other L2 tunneling protocols that may 872 be operating in the same environment, including L2TPv2 [RFC2661] and 873 L2F [RFC2341]. 875 While there are efficiencies gained by running L2TP directly over IP, 876 there are possible side effects as well. For instance, L2TP over IP 877 is not as NAT-friendly as L2TP over UDP. 879 4.1.2.1 L2TP Session Header Over UDP 881 The following session header format is utilized when operating L2TPv3 882 over UDP: 884 Figure 4.1.2.1: L2TPv3 Session Header over UDP 886 0 1 2 3 887 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 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 |T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Session ID | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Cookie (optional, maximum 64 bits)... 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 The T bit MUST be set to 0, indicating that this is a data message. 900 The x bits and Reserved field are reserved for future extensions. 901 All reserved values MUST be set to 0 on outgoing messages and ignored 902 on incoming messages. 904 The Ver field MUST be set to 3, indicating an L2TPv3 message. 906 Note that the initial bits 1, 4, 6 and 7 have meaning in L2TPv2 907 [RFC2661], and are deprecated and marked as reserved in L2TPv3. Thus, 908 for UDP mode on a system that supports both versions of L2TP, it is 909 important that the Ver field be inspected first to determine the 910 Version of the header before acting upon any of these bits. 912 The Session ID and Cookie fields are as defined in Section 4.1. 914 4.1.2.2 UDP Port Selection 916 The method for UDP Port Selection defined in this section is 917 identical to than defined for L2TPv2 [RFC2661]. 919 When negotiating a control connection over UDP, control messages MUST 920 be sent as UDP datagrams using the registered UDP port 1701 921 [RFC1700]. The initiator of an L2TP control connection picks an 922 available source UDP port (which may or may not be 1701), and sends 923 to the desired destination address at port 1701. The recipient picks 924 a free port on its own system (which may or may not be 1701) and 925 sends its reply to the initiator's UDP port and address, setting its 926 own source port to the free port it found. 928 Any subsequent traffic associated with this control connection 929 (either control traffic or data traffic from a session established 930 through this control connection) must use these same UDP ports. 932 It has been suggested that having the recipient choose an arbitrary 933 source port (as opposed to using the destination port in the packet 934 initiating the control connection, i.e., 1701) may make it more 935 difficult for L2TP to traverse some NAT devices. Implementations 936 should consider the potential implication of this capability before 937 choosing an arbitrary source port. A NAT device that can pass TFTP 938 traffic with variant UDP ports should be able to pass L2TP UDP 939 traffic since both protocols employ similar policies with regard to 940 UDP port selection. 942 4.1.2.3 UDP Checksum 944 The tunneled frames which L2TP carry often have their own checksum or 945 integrity checks, rendering the UDP checksum redundant for much of 946 the L2TP data message contents. Thus, UDP checksums MAY be disabled 947 in order to reduce the associated packet processing burden at the 948 L2TP endpoints. 950 The L2TP header itself does not have its own checksum or integrity 951 check. However, use of the L2TP Session ID and Cookie pair guards 952 against accepting an L2TP data message if corruption of the Session 953 ID or associated Cookie has occurred. When the L2-Specific-Sublayer 954 is present in the L2TP header, there is no built-in integrity check 955 for the information contained therein if UDP checksums or some other 956 integrity check is not employed. IPsec (Section 4.1.3) may be used 957 for strong integrity protection of the entire contents of L2TP data 958 messages. 960 UDP checksums MUST be enabled for L2TP control messages. 962 4.1.3 L2TP and IPsec 964 The L2TP data channel does not provide cryptographic security of any 965 kind. If the L2TP data channel operates over a public or untrusted IP 966 network where privacy of the L2TP data is of concern or sophisticated 967 attacks against L2TP are expected to occur, IPsec [RFC2401] MUST be 968 made available to secure the L2TP traffic. 970 Either L2TP over UDP or L2TP over IP may be secured with IPsec. 971 [RFC3193] defines the recommended method for securing L2TPv2. L2TPv3 972 possesses identical characteristics to IPsec as L2TPv2 when running 973 over UDP and implementations MUST follow the same recommendation. 974 When operating over IP directly, [RFC3193] still applies, though 975 references to UDP source and destination ports (in particular those 976 in Section 4 "IPsec Filtering details when protecting L2TP") may be 977 ignored. Instead, the selectors used to identify L2TPv3 traffic are 978 simply the source and destination IP address for the tunnel endpoints 979 together with the L2TPv3 IP protocol type, 115. 981 In addition to IP transport security, IPsec defines a mode of 982 operation that allows tunneling of IP packets. The packet-level 983 encryption and authentication provided by IPsec tunnel mode and that 984 provided by L2TP secured with IPsec provide an equivalent level of 985 security for these requirements. 987 IPsec also defines access control features that are required of a 988 compliant IPsec implementation. These features allow filtering of 989 packets based upon network and transport layer characteristics such 990 as IP address, ports, etc. In the L2TP tunneling model, analogous 991 filtering may be performed at the network layer above L2TP. These 992 network layer access control features may be handled at an LCCE via 993 vendor-specific authorization features, or at the network layer 994 itself by using IPsec transport mode end-to-end between the 995 communicating hosts. The requirements for access control mechanisms 996 are not a part of the L2TP specification and as such are outside the 997 scope of this document. 999 Protecting the L2TP packet stream with IPsec does, in turn, also 1000 protect the data within the tunneled session packets while 1001 transported from one LCCE to the other. Such protection must not be 1002 considered a substitution for end-to-end security between 1003 communicating hosts or applications. 1005 4.1.4 IP Fragmentation Issues 1007 Fragmentation and reassembly in network equipment generally requires 1008 significantly greater resources than sending or receiving a packet as 1009 a single unit. As such, it should be avoided whenever possible. Ideal 1010 solutions for avoiding fragmentation include proper configuration and 1011 management of MTU sizes between the Remote System, LCCE and across 1012 the IP network, as well as adaptive measures which operate with the 1013 originating host (e.g. [RFC1191], [RFC1981]) to reduce the packet 1014 sizes at the source. 1016 An LCCE MAY fragment a packet before encapsulating it in L2TP. For 1017 example, if an IPv4 packet arrives at an LCCE from a Remote System 1018 which, after encapsulation with its associated framing, L2TP and IP, 1019 does not fit in the available path MTU towards its LCCE peer, the 1020 local LCCE may perform IPv4 fragmentation on the packet before tunnel 1021 encapsulation. This creates two (or more) L2TP packets, each carrying 1022 an IPv4 fragment with its associated framing. This ultimately has the 1023 affect of placing the burden of fragmentation on the LCCE, but 1024 reassembly on the IPv4 destination host. 1026 If an IPv6 packet arrives at an LCCE from a Remote System which, 1027 after encapsulation with associated framing, L2TP and IP, does not 1028 fit in the available path MTU towards its L2TP peer, the Generic 1029 Packet Tunneling specification section 7.1 [RFC2473] SHOULD be 1030 followed, leading to either sending an ICMP Packet Too Big message to 1031 the data source, or fragmenting the resultant L2TP/IP packet to be 1032 reassembled by the L2TP peer. 1034 If the amount of traffic requiring fragmentation and reassembly is 1035 rather light, or there are sufficiently optimized mechanisms at the 1036 tunnel endpoints, fragmentation of the L2TP/IP packet may be 1037 sufficient for accommodating mismatched MTUs which cannot be managed 1038 by more efficient means. This method effectively emulates a larger 1039 MTU between tunnel endpoints and should work for any type of layer 2 1040 encapsulated packet. Note that IPv6 does not support "in-flight" 1041 fragmentation of data packets. Thus, unlike IPv4, the MTU of the path 1042 towards an L2TP peer must be known in advance (or the last resort 1043 IPv6 minimum MTU of 1280 bytes utilized) so that IPv6 fragmentation 1044 may occur at the LCCE. 1046 In summary, attempting to control the source MTU by communicating 1047 with the originating host, forcing that an MTU be sufficiently large 1048 on the path between LCCE peers to tunnel a frame from any other 1049 interface without fragmentation, fragmenting IP packets before 1050 encapsulation with L2TP/IP, or fragmenting the resultant L2TP/IP 1051 packet between the tunnel endpoints, are all valid methods for 1052 managing MTU mismatches. Some are clearly better than others 1053 depending on the given deployment. For example, a passive monitoring 1054 application using L2TP would certainly not wish to have ICMP messages 1055 sent to a traffic source. Further, if the links connecting a set of 1056 LCCEs has a very large MTU (e.g., SDH/SONET) and it is known that the 1057 MTU of all links being tunneled by L2TP have smaller MTUs (e.g. 1500 1058 bytes), then any IP fragmentation and reassembly enabled on the 1059 participating LCCEs would never be utilized. An implementation MUST 1060 implement at least one of the methods described in this section for 1061 managing mismatched MTUs, based on careful consideration of how the 1062 final product will be deployed. 1064 L2TP-specific fragmentation and reassembly methods (which may or may 1065 not depend on the characteristics of the type of link being tunneled, 1066 i.e., judicious packing of ATM cells) may be defined as well, but are 1067 outside the scope of this document. 1069 4.2 Reliable Delivery of Control Messages 1071 L2TP provides a lower level reliable delivery service for all control 1072 messages. The Nr and Ns fields of the control message header (see 1073 Section 3.2.1) belong to this delivery mechanism. The upper level 1074 functions of L2TP are not concerned with retransmission or ordering 1075 of control messages. The reliable control messaging mechanism is a 1076 sliding window mechanism that provides control message retransmission 1077 and congestion control. Each peer maintains separate sequence number 1078 state for each control connection. 1080 The message sequence number, Ns, begins at 0. Each subsequent 1081 message is sent with the next increment of the sequence number. The 1082 sequence number is thus a free-running counter represented modulo 1083 65536. The sequence number in the header of a received message is 1084 considered less than or equal to the last received number if its 1085 value lies in the range of the last received number and the preceding 1086 32767 values, inclusive. For example, if the last received sequence 1087 number was 15, then messages with sequence numbers 0 through 15, as 1088 well as 32784 through 65535, would be considered less than or equal. 1089 Such a message would be considered a duplicate of a message already 1090 received and ignored from processing. However, in order to ensure 1091 that all messages are acknowledged properly (particularly in the case 1092 of a lost ACK message), receipt of duplicate messages MUST be 1093 acknowledged by the reliable delivery mechanism. This acknowledgment 1094 may either piggybacked on a message in queue or sent explicitly via 1095 an ACK message. 1097 All control messages take up one slot in the control message sequence 1098 number space, except the ACK message. Thus, Ns is not incremented 1099 after an ACK message is sent. 1101 The last received message number, Nr, is used to acknowledge messages 1102 received by an L2TP peer. It contains the sequence number of the 1103 message the peer expects to receive next (e.g. the last Ns of a non- 1104 ACK message received plus 1, modulo 65536). While the Nr in a 1105 received ACK message is used to flush messages from the local 1106 retransmit queue (see below), the Nr of the next message sent is not 1107 updated by the Ns of the ACK message. Nr SHOULD be sanity-checked 1108 before flushing the retransmit queue. For instance, if the Nr 1109 received in a control message is greater than the last Ns sent plus 1 1110 modulo 65536, the control message is clearly invalid. 1112 The reliable delivery mechanism at a receiving peer is responsible 1113 for making sure that control messages are delivered in order and 1114 without duplication to the upper level. Messages arriving out of 1115 order may be queued for in-order delivery when the missing messages 1116 are received. Alternatively, they may be discarded, thus requiring a 1117 retransmission by the peer. When dropping out of order control 1118 packets, Nr MAY be updated before the packet is discarded. 1120 Each control connection maintains a queue of control messages to be 1121 transmitted to its peer. The message at the front of the queue is 1122 sent with a given Ns value and is held until a control message 1123 arrives from the peer in which the Nr field indicates receipt of this 1124 message. After a period of time (a recommended default is 1 second 1125 but SHOULD be configurable) passes without acknowledgment, the 1126 message is retransmitted. The retransmitted message contains the 1127 same Ns value, but the Nr value MUST be updated with the sequence 1128 number of the next expected message. 1130 Each subsequent retransmission of a message MUST employ an 1131 exponential backoff interval. Thus, if the first retransmission 1132 occurred after 1 second, the next retransmission should occur after 2 1133 seconds has elapsed, then 4 seconds, etc. An implementation MAY 1134 place a cap upon the maximum interval between retransmissions. This 1135 cap SHOULD be no less than 8 seconds per retransmission. If no peer 1136 response is detected after several retransmissions (a recommended 1137 default is 10, but MUST be configurable), the control connection and 1138 all associated sessions MUST be cleared. As it is the first message 1139 to establish a control connection, the SCCRQ MAY employ a different 1140 retransmission maximum than other control messages in order to help 1141 facilitate failover to alternate LCCEs in a timely fashion. 1143 When a control connection is being shut down for reasons other than 1144 loss of connectivity, the state and reliable delivery mechanisms MUST 1145 be maintained and operated for the full retransmission interval after 1146 the final message StopCCN message has been sent (e.g. 1 + 2 + 4 + 8 + 1147 8... seconds), or until the StopCCN message itself has been 1148 acknowledged. 1150 A sliding window mechanism is used for control message transmission 1151 and retransmission. Consider two peers, A and B. Suppose A 1152 specifies a Receive Window Size AVP with a value of N in the SCCRQ or 1153 SCCRP message. B is now allowed to have a maximum of N outstanding 1154 (e.g. unacknowledged) control messages. Once N messages have been 1155 sent, B must wait for an acknowledgment from A that advances the 1156 window before sending new control messages. An implementation may 1157 advertise a non-zero receive window as small or as large as it 1158 wishes, depending on its own ability to process incoming messages 1159 before sending an acknowledgement. Each peer MUST limit the number of 1160 unacknowledged messages it will send before receiving an 1161 acknowledgement by this Receive Window Size. The actual internal 1162 unacknowledged message send-queue depth may be further limited by 1163 local resource allocation or by dynamic slow-start and congestion- 1164 avoidance mechanisms. 1166 When retransmitting control messages, a slow start and congestion 1167 avoidance window adjustment procedure SHOULD be utilized. A 1168 recommended procedure is described in Appendix A. A peer MAY drop 1169 messages, but MUST NOT actively delay acknowledgment of messages as a 1170 technique for flow control of control messages. Appendix B contains 1171 examples of control message transmission, acknowledgment, and 1172 retransmission. 1174 4.3 Control Connection and Control Message Authentication 1176 L2TP incorporates an optional authentication and integrity check for 1177 all control messages. This mechanism consists of a computed one-way 1178 hash over the header and body of the L2TP control message, a pre- 1179 configured shared secret, and a local and remote nonce (random value) 1180 exchanged via the Nonce AVP. This per-message authentication and 1181 integrity check is designed to perform a mutual authentication 1182 between L2TP nodes, integrity checking of all control messages, and 1183 guard against control message spoofing and replay attacks that would 1184 otherwise be trivial to mount. 1186 At least one shared secret (password) MUST exist between 1187 communicating L2TP nodes to enable control message authentication. 1188 See Section 5.4.3 for details on calculation of the Message Digest 1189 and construction of the Nonce and Message Digest AVPs. 1191 L2TPv3 Control Connection and Control Message Authentication is 1192 similar to L2TPv2 [RFC2661] Tunnel Authentication in its use of a 1193 shared secret and one-way hash calculation. The principal difference 1194 is that, instead of computing the hash over selected contents of a 1195 received control message (e.g. the Challenge AVP and Message Type) as 1196 in L2TPv2, the entire message is used in the hash in L2TPv3. In 1197 addition, instead of including the hash digest in just the SCCRP and 1198 SCCCN messages, it is now included in all L2TP messages. 1200 The Control Message Authentication mechanism is optional, and may be 1201 disabled if both peers agree. For example, if IPsec is already being 1202 used for security and integrity checking between the LCCEs, the 1203 function of the L2TP mechanism becomes redundant and may be disabled. 1205 Presence of the Control Message Authentication Nonce AVP in an SCCRQ 1206 or SCCRP message serves as indication to a peer that Control Message 1207 Authentication is enabled. If an SCCRQ or SCCRP contains a Control 1208 Message Authentication Nonce AVP, the receiver of the message MUST 1209 respond with a Message Digest AVP in all subsequent messages sent. 1210 Control Connection and Control Message Authentication is always 1211 bidirectional, either both sides participate in authentication or 1212 neither do. 1214 If the Control Message Authentication is disabled, the Message Digest 1215 AVP still MAY be sent as an integrity check of the message. The 1216 integrity check is calculated as in Section 5.4.3, with an empty 1217 zero-length shared secret, local nonce, and remote nonce. If an 1218 invalid Message Digest is received, it should be assumed that the 1219 message has been corrupted in transit and the message dropped 1220 accordingly. 1222 Implementations MAY rate-limit control messages, particularly SCCRQ 1223 messages, upon receipt for performance reasons or to protect against 1224 denial of service attacks. 1226 4.4 Keepalive (Hello) 1228 L2TP employs a keepalive mechanism to detect loss of connectivity 1229 between a pair of LCCEs. This is accomplished by injecting Hello 1230 control messages (see Section 6.5) after a period of time has elapsed 1231 since the last data message or control message was received on an 1232 L2TP session or control connection, respectively. As with any other 1233 control message, if the Hello message is not reliably delivered, the 1234 sending LCCE declares that the control connection is down and resets 1235 its state for the control connection. This behavior ensures that a 1236 connectivity failure between the LCCEs is detected independently by 1237 each end of a control connection. 1239 Since the control channel is operated in-band with data traffic over 1240 the PSN, this single mechanism can be used to infer basic data 1241 connectivity between a pair of LCCEs for all sessions associated with 1242 the control connection. 1244 Periodic keepalive for the control connection MUST be implemented by 1245 sending a Hello if a period of time (a recommended default is 60 1246 seconds, but MUST be configurable) has passed without receiving any 1247 message (data or control) from the peer. An LCCE sending Hello 1248 messages across multiple control connections between the same LCCE 1249 endpoints MUST employ a jittered timer mechanism to prevent grouping 1250 of Hello messages. 1252 4.5 Forwarding Session Data Frames 1254 Once session establishment is complete, circuit frames are received 1255 at an LCCE, encapsulated in L2TP (with appropriate attention to 1256 framing as described in documents for the particular pseudowire 1257 type), and forwarded over the appropriate session. For every 1258 outgoing data message, the sender places the identifier specified in 1259 the Local Session ID AVP (received from peer during session 1260 establishment) in the Session ID field of the L2TP data header. In 1261 this manner, session frames are multiplexed and demultiplexed between 1262 a given pair of LCCEs. Multiple control connections may exist 1263 between a given pair of LCCEs, and multiple sessions may be 1264 associated with a given control connection. 1266 The peer LCCE receiving the L2TP data packet identifies the session 1267 with which the packet is associated by the Session ID in the data 1268 packet's header. The LCCE then checks the Cookie field in the data 1269 packet against the Cookie value received in the Assigned Cookie AVP 1270 during session establishment. It is important for implementers to 1271 note that the Cookie field check occurs after looking up the session 1272 context by the Session ID, and as such consists merely of a value 1273 match of the Cookie field and that stored in the retrieved context. 1274 There is no need to perform a lookup across the Session ID and Cookie 1275 as a single value. Any received data packets that contain invalid 1276 Session IDs or associated Cookie values MUST be dropped. Finally, 1277 the LCCE either forwards the network packet within the tunneled frame 1278 (e.g., as an LNS) or switches the frame to a circuit (e.g., as an 1279 LAC). 1281 4.6 Default L2-Specific Sublayer 1283 This document defines a default L2-Specific Sublayer (see Section 1284 3.2.2) format that a pseudowire may use for features such as 1285 sequencing support, L2 interworking, OAM, or other per-data-packet 1286 operations. The default L2-Specific Sublayer SHOULD be used by a 1287 given PW type to support these features if it is adequate, and its 1288 presence is requested by a peer during session negotiation. 1289 Alternative sublayers MAY be defined (e.g. an encapsulation with a 1290 larger Sequence Number field or timing information) and identified 1291 for use via the L2-Specific Sublayer Type AVP. 1293 Figure 4.6: Default L2-Specific Sublayer Format 1295 0 1 2 3 1296 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 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 |x|S|x|x|x|x|x|x| Sequence Number | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 The S (Sequence) bit is set to 1 when the Sequence Number contains a 1302 valid number for this sequenced frame. If the S bit is set to zero, 1303 the Sequence Number contents are undefined and MUST be ignored by the 1304 receiver. 1306 The Sequence Number field contains a free-running counter of 2^24 1307 sequence numbers. If the number in this field is valid, the S bit 1308 MUST be set to 1. The Sequence Number begins at zero, which is a 1309 valid sequence number. (In this way, implementations inserting 1310 sequence numbers do not have to "skip" zero when incrementing.) The 1311 sequence number in the header of a received message is considered 1312 less than or equal to the last received number if its value lies in 1313 the range of the last received number and the preceding (2^23-1) 1314 values, inclusive. 1316 4.6.1 Sequencing Data Packets 1318 The Sequence Number field may be used to detect lost, duplicate, or 1319 out-of-order packets within a given session. 1321 When L2 frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP 1322 data channel, this part of the link has the characteristic of being 1323 able to reorder, duplicate, or silently drop packets. Reordering may 1324 break some non-IP protocols or L2 control traffic being carried by 1325 the link. Silent dropping or duplication of packets may break 1326 protocols that assume per-packet indications of error, such as TCP 1327 header compression. While a common mechanism for packet sequence 1328 detection is provided, the sequence dependency characteristics of 1329 individual protocols are outside the scope of this document. 1331 If any protocol being transported by over L2TP data channels cannot 1332 tolerate misordering of data packets, packet duplication, or silent 1333 packet loss, sequencing may be enabled on some or all packets by 1334 using the S bit and Sequence Number field defined in the default L2- 1335 Specific Sublayer(see Section 4.6). For a given L2TP session, each 1336 LCCE is responsible for communicating to its peer the level of 1337 sequencing support that it requires of data packets that it receives. 1338 Mechanisms to advertise this information during session negotiation 1339 are provided (see Data Sequencing AVP in Section 5.4.4). 1341 When determining whether a packet is in or out of sequence, an 1342 implementation SHOULD utilize a method that is resilient to temporary 1343 dropouts in connectivity coupled with high per-session packet rates. 1344 The recommended method is outlined in Appendix C. 1346 4.7 L2TPv2/v3 Interoperability and Migration 1348 L2TPv2 and L2TPv3 environments should be able to coexist while a 1349 migration to L2TPv3 is made. Migration issues are discussed for each 1350 media type in this section. Most issues apply only to 1351 implementations that require both L2TPv2 and L2TPv3 operation. 1352 However, even L2TPv3-only implementations must at least be mindful of 1353 these issues in order to interoperate with implementations that 1354 support both versions. 1356 4.7.1 L2TPv3 over IP 1358 L2TPv3 implementations running strictly over IP with no desire to 1359 interoperate with L2TPv2 implementations may safely disregard most 1360 migration issues from L2TPv2. All control messages and data messages 1361 are sent as described in this document, without normative reference 1362 to RFC2661. 1364 If one wishes to tunnel PPP over L2TPv3, and fallback to L2TPv2 only 1365 if it is not available, then L2TPv3 over UDP with the automatic 1366 fallback as described in section 4.7.3 MUST be used. There is no 1367 deterministic method for automatic fallback from L2TPv3 over IP to 1368 either L2TPv2 or L2TPv3 over UDP. One could infer whether L2TPv3 over 1369 IP is supported by sending an SCCRQ and waiting for a response, but 1370 this could be problematic during periods of packet loss between L2TP 1371 nodes. 1373 4.7.2 L2TPv3 over UDP 1375 The format of the L2TPv3 over UDP header is defined in Section 1376 4.1.2.1. 1378 When operating over UDP, L2TPv3 uses the same port (1701) as L2TPv2 1379 and shares the first two octets of header format with L2TPv2. The Ver 1380 field is used to distinguish L2TPv2 packets from L2TPv3 packets. If 1381 an implementation is capable of operating in L2TPv2 or L2TPv3 modes, 1382 it is possible to automatically detect whether a peer can support 1383 L2TPv2 or L2TPv3 and operate accordingly. The details of this 1384 fallback capability is defined in the following section. 1386 4.7.3 Automatic L2TPv2 Fallback 1388 When running over UDP, an implementation may detect whether a peer is 1389 L2TPv3-capable by sending a special SCCRQ that is properly formatted 1390 for both L2TPv2 and L2TPv3. This is accomplished by sending an SCCRQ 1391 with its Ver field set to 2 (for L2TPv2), and ensuring that any 1392 L2TPv3-specific AVPs (i.e. AVPs present within this document and not 1393 defined within RFC 2661) within the message are sent with each M bit 1394 set to 0, and all L2TPv2 AVPs present as they would be for L2TPv2. 1395 This is done so that L2TPv3 AVPs will be ignored by an L2TPv2-only 1396 implementation. Note that, in both L2TPv2 and L2TPv3, the value 1397 contained in the space of the control message header utilized by the 1398 32-bit Control Connection ID in L2TPv3, and the 16-bit Tunnel ID and 1399 16-bit Session ID in L2TPv2, is always 0 for an SCCRQ. This 1400 effectively hides the fact that there are a pair of 16-bit fields in 1401 L2TPv2, and a single 32-bit field in L2TPv3. 1403 If the peer implementation is L2TPv3-capable, a control message with 1404 Ver set to 3 and corresponding header and message format will be sent 1405 in response to the SCCRQ. Operation may then continue as L2TPv3. If 1406 a message is received with Ver set to 2, it must be assumed that the 1407 peer implementation is L2TPv2-only and fallback to L2TPv2 mode may 1408 safely occur. 1410 Note Well: The L2TPv2/v3 auto-detection mode requires that all L2TPv3 1411 implementations over UDP be liberal in acceptance of an SCCRQ control 1412 message with the Ver field set to 2 or 3 and the presence of L2TPv2- 1413 specific AVPs. An L2TPv3-only implementation MUST ignore all L2TPv2 1414 AVPs (e.g. those defined in RFC 2661 and not in this document) within 1415 an SCCRQ with the Ver field set to 2 (even if the M bit is set on the 1416 L2TPv2-specific AVPs). 1418 5. Control Message Attribute Value Pairs 1420 To maximize extensibility while permitting interoperability, a 1421 uniform method for encoding message types is used throughout L2TP. 1422 This encoding will be termed AVP (Attribute Value Pair) for the 1423 remainder of this document. 1425 5.1 AVP Format 1427 Each AVP is encoded as follows: 1429 Figure 5.1: AVP Format 1431 0 1 2 3 1432 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 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 |M|H| rsvd | Length | Vendor ID | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | Attribute Type | Attribute Value ... 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 (until Length is reached) | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 The first six bits comprise a bit mask that describes the general 1442 attributes of the AVP. Two bits are defined in this document; the 1443 remaining bits are reserved for future extensions. Reserved bits 1444 MUST be set to 0 when sent and ignored upon receipt. 1446 Mandatory (M) bit: Controls the behavior required of an 1447 implementation that receives an unrecognized AVP. The M bit of a 1448 given AVP MUST only be inspected and acted upon if the AVP is 1449 unrecognized (see Section 5.2). 1451 Hidden (H) bit: Identifies the hiding of data in the Attribute Value 1452 field of an AVP. This capability can be used to avoid the passing of 1453 sensitive data, such as user passwords, as cleartext in an AVP. 1454 Section 5.3 describes the procedure for performing AVP hiding. 1456 Length: Contains the number of octets (including the Overall Length 1457 and bit mask fields) contained in this AVP. The Length may be 1458 calculated as 6 + the length of the Attribute Value field in octets. 1460 The field itself is 10 bits, permitting a maximum of 1023 octets of 1461 data in a single AVP. The minimum Length of an AVP is 6. If the 1462 Length is 6, then the Attribute Value field is absent. 1464 Vendor ID: The IANA assigned "SMI Network Management Private 1465 Enterprise Codes" [RFC1700] value. The value 0, corresponding to 1466 IETF adopted attribute values, is used for all AVPs defined within 1467 this document. Any vendor wishing to implement its own L2TP 1468 extensions can use its own Vendor ID along with private Attribute 1469 values, guaranteeing that they will not collide with any other 1470 vendor's extensions or future IETF extensions. Note that there are 1471 16 bits allocated for the Vendor ID, thus limiting this feature to 1472 the first 65,535 enterprises. 1474 Attribute Type: A 2-octet value with a unique interpretation across 1475 all AVPs defined under a given Vendor ID. 1477 Attribute Value: This is the actual value as indicated by the Vendor 1478 ID and Attribute Type. It follows immediately after the Attribute 1479 Type field and runs for the remaining octets indicated in the Length 1480 (i.e., Length minus 6 octets of header). This field is absent if the 1481 Length is 6. 1483 In the event that the 16-bit Vendor ID space is exhausted, vendor- 1484 specific AVPs with a 32-bit Vendor ID MUST be encapsulated in the 1485 following manner: 1487 Figure 5.2: Extended Vendor ID AVP Format 1489 0 1 2 3 1490 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 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 |M|H| rsvd | Length | 0 | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | AVP-TBA-0 | 32 bit Vendor ID ... 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | Attribute Type | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | Attribute Value ... 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 (until Length is reached) | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 This AVP encodes a vendor-specific AVP with a 32-bit Vendor ID space 1504 within the Attribute Value field. It is necessary only in the event 1505 that the 16-bit Vendor ID space is exhausted. Multiple AVPs of this 1506 type may exist in any message. The 16-bit Vendor ID MUST be 0 1507 indicating that this is an IETF defined AVP, and the Attribute Type 1508 MUST be AVP-TBA-0 indicating that what follows is a vendor-specific 1509 AVP with a 32-bit Vendor ID code. This AVP MAY be hidden (the H bit 1510 MAY be 0 or 1). The M bit for this AVP MUST be set to 0. The Length 1511 of the AVP is 12 plus the length of the Attribute Value. 1513 5.2 Mandatory AVPs and Setting the M Bit 1515 If the M bit is set on an AVP that is unrecognized by its recipient, 1516 the session or control connection associated with the control message 1517 containing the AVP MUST be shutdown. If the control message 1518 containing the unrecognized AVP is associated with a session (e.g. an 1519 ICRQ, ICRP, ICCN, SLI, etc.) then the session MUST be issued a CDN 1520 with a Result Code of 2 and Error Code of 8 as defined in section 1521 5.4.2. and shutdown. If the control message containing the 1522 unrecognized AVP is associated with establishment or maintenance of a 1523 Control Connection (e.g. SCCRQ, SCCRP, SCCCN, Hello) then the 1524 associated Control Connection MUST be issued a StopCCN with Result 1525 Code of 2 and Error Code of 8 as defined in section 5.4.2. and 1526 shutdown. If the M bit is not set on an unrecognized AVP, the AVP 1527 MUST be ignored when received, processing the control message as if 1528 the AVP was not present. 1530 Receipt of an unrecognized AVP that has the M bit set is catastrophic 1531 to the session or control connection with which it is associated. 1532 Thus, the M bit should only be set for AVPs that are deemed crucial 1533 to proper operation of the session or control connection by the 1534 sender. AVPs that are considered crucial by the sender may vary by 1535 application and configured options. In no case shall a receiver of 1536 an AVP "validate" if the M bit is set on a recognized AVP. If the AVP 1537 is recognized (as all AVPs defined in this document MUST be for a 1538 compliant L2TPv3 specification), then by definition the M bit is of 1539 no consequence. 1541 The sender of an AVP is free to set its M bit to 1 or 0 based on 1542 whether the configured application strictly requires the value 1543 contained in the AVP to be recognized or not. For example, "Automatic 1544 L2TPv2 Fallback" (Section 4.7.3), requires the setting of the M bit 1545 on all new L2TPv3 AVPs to zero if fallback to L2TPv2 is supported and 1546 desired, and 1 if not. 1548 The M bit is useful as extra assurance for support of critical AVP 1549 extensions. However, more explicit methods may be available to 1550 determine support for a given feature rather than using the M bit 1551 alone. For example, if a new AVP is defined in a message for which 1552 there is always a message reply (i.e. an ICRQ, ICRP, SCCRQ or SCCRP 1553 message) rather than simply sending an AVP in the message with the M 1554 bit set, availability of the extension may be identified by sending 1555 an AVP in the request message and expecting a corresponding AVP in a 1556 reply message. This more explicit method, when possible, is 1557 preferred. 1559 The M bit also plays a role in determining whether or not a malformed 1560 or out-of-range value within an AVP should be ignored or result in 1561 termination of a session or control channel. See Section 7.1 for more 1562 details on this. 1564 5.3 Hiding of AVP Attribute Values 1566 The H bit in the header of each AVP provides a mechanism to indicate 1567 to the receiving peer whether the contents of the AVP are hidden or 1568 present in cleartext. This feature can be used to hide sensitive 1569 control message data such as user passwords, IDs, or other vital 1570 information. 1572 The H bit MUST only be set if (1) a shared secret exists between the 1573 LCCEs and (2) Control Connection and Control Message Authentication 1574 is enabled (see Section 4.3). If the H bit is set in any AVP(s) in a 1575 given control message, at least one Random Vector AVP must also be 1576 present in the message and MUST precede the first AVP having an H bit 1577 of 1. 1579 The shared secret between LCCEs is used to derive a unique shared key 1580 for hiding and unhiding calculations. The derived shared key is 1581 obtained via an HMAC-MD5 keyed hash [RFC2104], with the key 1582 consisting of the shared secret, and with the data being hashed 1583 consisting of a single octet containing the value 1. 1585 shared_key = HMAC_MD5 (shared_secret, 1) 1587 Hiding an AVP value is done in several steps. The first step is to 1588 take the length and value fields of the original (cleartext) AVP and 1589 encode them into a Hidden AVP Subformat as follows: 1591 Figure 5.3: Hidden AVP Subformat 1593 0 1 2 3 1594 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 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 | Length of Original Value | Original Attribute Value ... 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 ... | Padding ... 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 Length of Original Attribute Value: This is length of the Original 1603 Attribute Value to be obscured in octets. This is necessary to 1604 determine the original length of the Attribute Value that is lost 1605 when the additional Padding is added. 1607 Original Attribute Value: Attribute Value that is to be obscured. 1609 Padding: Random additional octets used to obscure length of the 1610 Attribute Value that is being hidden. 1612 To mask the size of the data being hidden, the resulting subformat 1613 MAY be padded as shown above. Padding does NOT alter the value 1614 placed in the Length of Original Attribute Value field, but does 1615 alter the length of the resultant AVP that is being created. For 1616 example, if an Attribute Value to be hidden is 4 octets in length, 1617 the unhidden AVP length would be 10 octets (6 + Attribute Value 1618 length). After hiding, the length of the AVP will become 6 + 1619 Attribute Value length + size of the Length of Original Attribute 1620 Value field + Padding. Thus, if Padding is 12 octets, the AVP length 1621 will be 6 + 4 + 2 + 12 = 24 octets. 1623 Next, an MD5 [RFC1321] hash is performed (in network byte order) on 1624 the concatenation of the following: 1626 + the 2-octet Attribute number of the AVP 1627 + the shared key 1628 + an arbitrary length random vector 1630 The value of the random vector used in this hash is passed in the 1631 value field of a Random Vector AVP. This Random Vector AVP must be 1632 placed in the message by the sender before any hidden AVPs. The same 1633 random vector may be used for more than one hidden AVP in the same 1634 message, but not for hiding two or more instances of an AVP with the 1635 same Attribute Type unless the Attribute Values in the two AVPs are 1636 also identical. When a different random vector is used for the 1637 hiding of subsequent AVPs, a new Random Vector AVP MUST be placed in 1638 the control message before the first AVP to which it applies. 1640 The MD5 hash value is then XORed with the first 16-octet (or less) 1641 segment of the Hidden AVP Subformat and placed in the Attribute Value 1642 field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 1643 octets, the Subformat is transformed as if the Attribute Value field 1644 had been padded to 16 octets before the XOR. Only the actual octets 1645 present in the Subformat are modified, and the length of the AVP is 1646 not altered. 1648 If the Subformat is longer than 16 octets, a second one-way MD5 hash 1649 is calculated over a stream of octets consisting of the shared key 1650 followed by the result of the first XOR. That hash is XORed with the 1651 second 16-octet (or less) segment of the Subformat and placed in the 1652 corresponding octets of the Value field of the Hidden AVP. 1654 If necessary, this operation is repeated, with the shared key used 1655 along with each XOR result to generate the next hash to XOR the next 1656 segment of the value with. 1658 The hiding method was adapted from [RFC2865], which was taken from 1659 the "Mixing in the Plaintext" section in the book "Network Security" 1660 by Kaufman, Perlman and Speciner [KPS]. A detailed explanation of 1661 the method follows: 1663 Call the shared key S, the Random Vector RV, and the Attribute Type 1664 A. Break the value field into 16-octet chunks p1, p2, etc., with the 1665 last one padded at the end with random data to a 16-octet boundary. 1666 Call the ciphertext blocks c(1), c(2), etc. We will also define 1667 intermediate values b1, b2, etc. 1669 b_1 = MD5 (A + S + RV) c_1 = p_1 xor b_1 1670 b_2 = MD5 (S + c_1) c_2 = p_2 xor b_2 1671 . . 1672 . . 1673 . . 1674 b_i = MD5 (S + c_i-1) c_i = p_i xor b_i 1676 The String will contain c_1 + c_2 +...+ c_i, where + denotes 1677 concatenation. 1679 On receipt, the random vector is taken from the last Random Vector 1680 AVP encountered in the message prior to the AVP to be unhidden. The 1681 above process is then reversed to yield the original value. 1683 5.4 AVP Summary 1685 The following sections contain a list of all L2TP AVPs defined in 1686 this document. 1688 Following the name of the AVP is a list indicating the message types 1689 that utilize each AVP. After each AVP title follows a short 1690 description of the purpose of the AVP, a detail (including a graphic) 1691 of the format for the Attribute Value, and any additional information 1692 needed for proper use of the AVP. 1694 5.4.1 General Control Message AVPs 1696 Message Type (All Messages) 1698 The Message Type AVP, Attribute Type 0, identifies the control 1699 message herein and defines the context in which the exact meaning of 1700 the following AVPs will be determined. 1702 The Attribute Value field for this AVP has the following format: 1704 0 1 1705 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 | Message Type | 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 The Message Type is a 2-octet unsigned integer. 1712 The Message Type AVP MUST be the first AVP in a message, immediately 1713 following the control message header (defined in Section 3.2.1). See 1714 Section 3.1 for the list of defined control message types and their 1715 identifiers. 1717 The Mandatory (M) bit within the Message Type AVP has special 1718 meaning. Rather than an indication as to whether the AVP itself 1719 should be ignored if not recognized, it is an indication as to 1720 whether the control message itself should be ignored. If the M bit 1721 is set within the Message Type AVP and the Message Type is unknown to 1722 the implementation, the control connection MUST be cleared. If the M 1723 bit is not set, then the implementation may ignore an unknown message 1724 type. The M bit MUST be set to 1 for all message types defined in 1725 this document. This AVP MAY NOT be hidden (the H bit MUST be 0). 1726 The Length of this AVP is 8. 1728 A vendor-specific control message may be defined by setting the 1729 Vendor ID of the Message Type AVP to a value other than the IETF 1730 Vendor ID of 0 (see Section 5.1). The Message Type AVP MUST still be 1731 the first AVP in the control message. 1733 Message Digest (All Messages) 1735 The Message Digest AVP, Attribute Type AVP-TBA-1, is used as an 1736 integrity and authentication check of the L2TP Control Message header 1737 and body. 1739 The Attribute Value field for this AVP has the following format: 1741 0 1 2 3 1742 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 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | Digest Type | Message Digest ... 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 ... (16 or 20 octets) | 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 Where Digest Type is a one octet integer indicating the Digest 1753 calculation algorithm: 1754 0 HMAC-MD5 [RFC2104] 1755 1 HMAC-SHA-1 [RFC2104] 1757 Digest type 0 (HMAC-MD5) MUST be supported, Digest Type 1 (HMAC-SHA- 1758 1) SHOULD be supported. 1760 The Message Digest is of variable length and contains the result of 1761 the control message authenticity and integrity calculation. For 1762 Digest Type 0 (HMAC-MD5) the length of the digest MUST be 16 bytes. 1763 For Digest Type 1 (SHA-1) the digest MUST be 20 bytes. 1765 If Control Connection and Control Message Authentication is enabled, 1766 at least one Message Digest AVP MUST present in all messages and MUST 1767 be placed immediately after the Message Type AVP. This forces the 1768 Message Digest AVP to begin at a well-known and fixed offset. A 1769 second Message Digest AVP MAY be present in a message, and MUST be 1770 placed directly after the first Message Digest AVP. 1772 The shared secret between LCCEs is used to derive a unique shared key 1773 for Control Connection and Control Message Authentication 1774 calculations. The derived shared key is obtained via an HMAC-MD5 1775 keyed hash [RFC2104], with the key consisting of the shared secret, 1776 and with the data being hashed consisting of a single octet 1777 containing the value 2. 1779 shared_key = HMAC_MD5 (shared_secret, 2) 1781 Calculation of the digest is as follows for all messages other than 1782 the SCCRQ (where '+' refers to concatenation): 1784 Digest = HMAC_Hash (shared_key, local_nonce + remote_nonce + 1785 control_message) 1787 HMAC_Hash: HMAC Hashing algorithm identified by the Digest Type 1788 (MD5 or SHA1) 1790 local_nonce: Nonce chosen locally and advertised to the remote 1791 LCCE. 1793 remote_nonce: Nonce received from the remote LCCE 1795 (The local_nonce and remote_nonce are advertised via the Control 1796 Message Authentication Nonce AVP, also defined in this section.) 1798 shared_key: Derived shared key for this Control Connection 1800 control_message: The entire contents of the L2TP Control Message, 1801 including the Control Message header and all AVPs. Note that the 1802 Control Message header in this case begins after the 0 Session ID 1803 (see Section 4.1.1.2) when running over IP, and after the UDP 1804 header when running over UDP (see Section 4.1.2.1). 1806 When calculating the Message Digest, the Message Digest AVP MUST be 1807 present within the control message with the Digest Type set to its 1808 proper value, but the Message Digest itself set to zeros. 1810 When receiving a control message, the contents of the Message Digest 1811 AVP MUST be compared against the expected digest value based on local 1812 calculation. This is done by performing the same digest calculation 1813 above, with the local_nonce and remote_nonce reversed. This message 1814 authenticity and integrity checking MUST be performed before 1815 utilizing any information contained within the control message. If 1816 the calculation fails, the message MUST be dropped. 1818 The SCCRQ has special treatment as it is the initial message 1819 commencing a new Control Connection. As such, there is only one nonce 1820 available. Since the nonce is present within the message itself as 1821 part of the Control Message Authentication Nonce AVP, there is no 1822 need to use it in the calculation explicitly. Calculation of the 1823 SCCRQ Digest is performed as follows: 1825 Digest = HMAC_Hash (shared_key, control_message) 1827 To allow for graceful switchover to a new shared secret or hash 1828 algorithm, two Message Digest AVPs MAY be present in a control 1829 message and two shared secrets MAY be configured for a given LCCE. 1830 If two Message Digest AVPs are received in a control message, the 1831 message MUST be accepted if either Message Digest is valid. If two 1832 shared secrets are configured, each (separately) MUST be used for 1833 calculating a digest to be compared to the Message Digest(s) 1834 received. When calculating a digest for a control message, the Value 1835 for both of the Message Digest AVPs MUST be set to zero. 1837 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1838 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1839 Length is 23 for Digest Type 1 (HMAC-MD5), and 27 for Digest Type 2 1840 (SHA-1). 1842 Control Message Authentication Nonce (SCCRQ, SCCRP) 1844 The Control Message Authentication Nonce AVP, Attribute Type AVP- 1845 TBA-15, MUST contain a cryptographically random value [RFC1750]. This 1846 value is used for Control Message Authentication. 1848 The Attribute Value field for this AVP has the following format: 1850 0 1 2 3 1851 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 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 | Nonce ... (arbitrary number of octets) 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 The Nonce is of arbitrary length, though at least 16 octets is 1857 recommended. The Nonce contains the random value for use in the 1858 Control Message Authentication hash calculation (see Message Digest 1859 AVP definition in this section). 1861 If Control Connection and Message Authentication is enabled, this AVP 1862 MUST be present in the SCCRQ and SCCRP messages. 1864 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this 1865 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length of 1866 this AVP is 6 plus the length of the Nonce. 1868 Random Vector (All Messages) 1870 The Random Vector AVP, Attribute Type 36, MUST contain a 1871 cryptographically random value [RFC1750]. This value is used for AVP 1872 Hiding. 1874 The Attribute Value field for this AVP has the following format: 1876 0 1 2 3 1877 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 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 | Random Octet String ... (arbitrary number of octets) 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 The Random Octet String is of arbitrary length, though at least 16 1883 octets is recommended. The string contains the random vector for use 1884 in computing the MD5 hash to retrieve or hide the Attribute Value of 1885 a hidden AVP (see Section 5.3). 1887 More than one Random Vector AVP may appear in a message, in which 1888 case a hidden AVP uses the Random Vector AVP most closely preceding 1889 it. As such, at least one Random Vector AVP MUST precede the first 1890 AVP with the H bit set. 1892 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1893 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1894 Length of this AVP is 6 plus the length of the Random Octet String. 1896 5.4.2 Result and Error Codes 1898 Result Code (StopCCN, CDN) 1900 The Result Code AVP, Attribute Type 1, indicates the reason for 1901 terminating the control channel or session. 1903 The Attribute Value field for this AVP has the following format: 1905 0 1 2 3 1906 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 | Result Code | Error Code (optional) | 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 | Error Message ... (optional, arbitrary number of octets) | 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1913 The Result Code is a 2-octet unsigned integer. The optional Error 1914 Code is a 2-octet unsigned integer. An optional Error Message can 1915 follow the Error Code field. Presence of the Error Code and Message 1916 is indicated by the AVP Length field. The Error Message contains an 1917 arbitrary string providing further (human-readable) text associated 1918 with the condition. Human-readable text in all error messages MUST 1919 be provided in the UTF-8 charset [RFC3629] using the Default Language 1920 [RFC2277]. 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 is 8 if there is no Error Code or Message, 10 if there is an 1925 Error Code and no Error Message, or 10 plus the length of the Error 1926 Message if there is an Error Code and Message. 1928 Defined Result Code values for the StopCCN message are as follows: 1930 0 - Reserved. 1931 1 - General request to clear control connection. 1932 2 - General error, Error Code indicates the problem. 1933 3 - Control channel already exists. 1934 4 - Requester is not authorized to establish a control channel. 1935 5 - The protocol version of the requester is not supported, 1936 Error Code indicates highest version supported. 1937 6 - Requester is being shut down. 1939 7 - Finite state machine error or timeout 1941 General Result Code values for the CDN message are as follows: 1943 0 - Reserved. 1944 1 - Session disconnected due to loss of carrier or 1945 circuit disconnect. 1946 2 - Session disconnected for the reason indicated in Error Code. 1947 3 - Session disconnected for administrative reasons. 1948 4 - Session establishment failed due to lack of appropriate 1949 facilities being available (temporary condition). 1950 5 - Session establishment failed due to lack of appropriate 1951 facilities being available (permanent condition). 1952 6 - 11 Reserved 1953 RC-TBA-1 - Session not established due to losing tie breaker. 1954 RC-TBA-2 - Session not established due to unsupported PW type. 1955 RC-TBA-3 - Session not established, sequencing required without 1956 valid L2-Specific Sublayer. 1957 RC-TBA-4 - Finite state machine error or timeout. 1959 Additional service-specific Result Codes are defined outside this 1960 document. 1962 The Error Codes defined below pertain to types of errors that are not 1963 specific to any particular L2TP request, but rather to protocol or 1964 message format errors. If an L2TP reply indicates in its Result Code 1965 that a general error occurred, the General Error value should be 1966 examined to determine what the error was. The currently defined 1967 General Error codes and their meanings are as follows: 1969 0 - No general error. 1970 1 - No control connection exists yet for this pair of LCCEs. 1971 2 - Length is wrong. 1972 3 - One of the field values was out of range. 1973 4 - Insufficient resources to handle this operation now. 1974 5 - Invalid Session ID. 1975 6 - A generic vendor-specific error occurred. 1976 7 - Try another. If initiator is aware of other possible responder 1977 destinations, it should try one of them. This can be 1978 used to guide an LAC or LNS based on policy. 1979 8 - The session or control connection was shut down due to receipt of 1980 an unknown AVP with the M bit set (see Section 5.2). The Error 1981 Message SHOULD contain the attribute of the offending AVP in 1982 (human-readable) text form. 1983 9 - Try another directed. If an LAC or LNS is aware of other 1984 possible destinations, it should inform the initiator of the 1985 control connection or session. The Error Message MUST contain a 1986 comma-separated list of addresses from which the initiator may 1987 choose. If the L2TP data channel runs over IPv4, then this would 1988 be a comma-separated list of IP addresses in the canonical 1989 dotted-decimal format (e.g. "192.0.2.1, 192.0.2.2, 192.0.2.3") 1990 in the UTF-8 charset [RFC3629] using the Default Language 1991 [RFC2277]. If there are no servers for the LAC or LNS to 1992 suggest, then Error Code 7 should be used. For IPv4, the 1993 delimiter between addresses MUST be precisely a single comma 1994 and a single space. For IPv6, each literal address MUST be 1995 enclosed in "[" and "]" characters, following the encoding 1996 described in [RFC2732]. 1998 When a General Error Code of 6 is used, additional information about 1999 the error SHOULD be included in the Error Message field. A vendor- 2000 specific AVP MAY be sent to more precisely detail a vendor-specific 2001 problem. 2003 5.4.3 Control Connection Management AVPs 2005 Control Connection Tie Breaker (SCCRQ) 2007 The Control Connection Tie Breaker AVP, Attribute Type 5, indicates 2008 that the sender desires a single control connection to exist between 2009 a given pair of LCCEs. 2011 The Attribute Value field for this AVP has the following format: 2013 0 1 2 3 2014 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 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2016 | Control Connection Tie Breaker Value ... 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 ... (64 bits) | 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2021 The Control Connection Tie Breaker Value is an 8-octet random value 2022 that is used to choose a single control connection when two LCCEs 2023 request a control connection concurrently. The recipient of a SCCRQ 2024 must check to see if a SCCRQ has been sent to the peer; if so, a tie 2025 has been detected. In this case, the LCCE must compare its Control 2026 Connection Tie Breaker value with the one received in the SCCRQ. The 2027 lower value "wins", and the "loser" MUST discard its control 2028 connection, sending a StopCCN if the SCCRQ that it had sent was 2029 acknowledged by the receiving peer. In the case in which a tie 2030 breaker is present on both sides and the value is equal, both sides 2031 MUST discard their control connections and restart control connection 2032 negotiation with a new, random tie breaker value. 2034 If a tie breaker is received and an outstanding SCCRQ has no tie 2035 breaker value, the initiator that included the Control Connection Tie 2036 Breaker AVP "wins". If neither side issues a tie breaker, then two 2037 separate control connections are opened. 2039 Applications which employ a distinct and well-known initiator have no 2040 need for tie-breaking, and this AVP MAY be omitted and the tie- 2041 breaking functionality disabled. Applications which require tie- 2042 breaking also require that an LCCE be uniquely identifiable upon 2043 receipt of an SCCRQ. For L2TP over IP, this MUST be accomplished via 2044 the Router ID AVP. 2046 Note that in [RFC2661], this AVP was referred to as the "Tie-Breaker 2047 AVP". Here, the AVP serves the same purpose and has the same 2048 attribute value and composition. The name was changed simply to 2049 distinguish between the Session and Control Connection Tie Breaker 2050 AVP. 2052 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 2053 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2054 Length of this AVP is 14. 2056 Host Name (SCCRQ, SCCRP) 2058 The Host Name AVP, Attribute Type 7, indicates the name of the 2059 issuing LAC or LNS, encoded in the US-ASCII charset. 2061 The Attribute Value field for this AVP has the following format: 2063 0 1 2 3 2064 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 2065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2066 | Host Name ... (arbitrary number of octets) 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 The Host Name is of arbitrary length, but MUST be at least 1 octet. 2071 This name should be as broadly unique as possible; for hosts 2072 participating in DNS [RFC1034], a host name with fully qualified 2073 domain would be appropriate. The Host Name AVP and/or Router ID AVP 2074 MUST be used to identify an LCCE as described in Section 3.3. 2076 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 2077 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2078 Length of this AVP is 6 plus the length of the Host Name. 2080 Router ID (SCCRQ, SCCRP) 2082 The Router ID AVP, Attribute Type AVP-TBA-2, is an identifier used to 2083 identify an LCCE for control connection setup, tie breaking, and/or 2084 tunnel authentication. 2086 The Attribute Value field for this AVP has the following format: 2088 0 1 2 3 2089 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2091 | Router Identifier | 2092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 The Router Identifier is a 4-octet unsigned integer. Its value is 2095 unique for a given LCCE, per Section 8.1 of [RFC2072]. The Host Name 2096 AVP and/or Router ID AVP MUST be used to identify an LCCE as 2097 described in Section 3.3. 2099 Implementations MUST NOT assume that Router Identifier is a valid IP 2100 address. The Router Identifier for L2TP over IPv6 can be obtained 2101 from an IPv4 address (if available) or via unspecified 2102 implementation-specific means. 2104 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 2105 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2106 Length of this AVP is 10. 2108 Vendor Name (SCCRQ, SCCRP) 2110 The Vendor Name AVP, Attribute Type 8, contains a vendor-specific 2111 (possibly human-readable) string describing the type of LAC or LNS 2112 being used. 2114 The Attribute Value field for this AVP has the following format: 2116 0 1 2 3 2117 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 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 | Vendor Name ... (arbitrary number of octets) 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 The Vendor Name is the indicated number of octets representing the 2123 vendor string. Human-readable text for this AVP MUST be provided in 2124 the US-ASCII charset [RFC1958, RFC2277]. 2126 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2127 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2128 (before hiding) of this AVP is 6 plus the length of the Vendor Name. 2130 Assigned Control Connection ID (SCCRQ, SCCRP, StopCCN) 2132 The Assigned Control Connection ID AVP, Attribute Type AVP-TBA-3, 2133 contains the ID being assigned to this control connection by the 2134 sender. 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 | Assigned Control Connection ID | 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 The Assigned Control Connection ID is a 4-octet non-zero unsigned 2145 integer. 2147 The Assigned Control Connection ID AVP establishes the identifier 2148 used to multiplex and demultiplex multiple control connections 2149 between a pair of LCCEs. Once the Assigned Control Connection ID AVP 2150 has been received by an LCCE, the Control Connection ID specified in 2151 the AVP MUST be included in the Control Connection ID field of all 2152 control packets sent to the peer for the lifetime of the control 2153 connection. Before the Assigned Control Connection ID AVP is 2154 received from a peer, all control messages MUST be sent to that peer 2155 with a Control Connection ID value of 0 in the header. Because a 2156 Control Connection ID value of 0 is used in this special manner, the 2157 zero value MUST NOT be sent as an Assigned Control Connection ID 2158 value. 2160 Under certain circumstances, an LCCE may need to send a StopCCN to a 2161 peer without having yet received an Assigned Control Connection ID 2162 AVP from the peer (i.e. SCCRQ sent, no SCCRP received yet). In this 2163 case, the Assigned Control Connection ID AVP that had been sent to 2164 the peer earlier (i.e. in the SCCRQ) MUST be sent as the Assigned 2165 Control Connection ID AVP in the StopCCN. This policy allows the 2166 peer to try to identify the appropriate control connection via a 2167 reverse lookup. 2169 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2170 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2171 (before hiding) of this AVP is 10. 2173 Receive Window Size (SCCRQ, SCCRP) 2175 The Receive Window Size AVP, Attribute Type 10, specifies the receive 2176 window size being offered to the remote peer. 2178 The Attribute Value field for this AVP has the following format: 2180 0 1 2181 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 | Window Size | 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 The Window Size is a 2-octet unsigned integer. 2188 If absent, the peer must assume a Window Size of 4 for its transmit 2189 window. 2191 The remote peer may send the specified number of control messages 2192 before it must wait for an acknowledgment. See Section 4.2 for more 2193 information on reliable control message delivery. 2195 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 2196 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2197 Length of this AVP is 8. 2199 Pseudowire Capabilities List (SCCRQ, SCCRP) 2201 The Pseudowire Capabilities List (PW Capabilities List) AVP, 2202 Attribute Type AVP-TBA-4, indicates the L2 payload types the sender 2203 can support. The specific payload type of a given session is 2204 identified by the Pseudowire Type AVP. 2206 The Attribute Value field for this AVP has the following format: 2208 0 1 2 3 2209 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 2210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 | PW Type 0 | ... | 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 | ... | PW Type N | 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 Defined PW types that may appear in this list are managed by IANA and 2217 will appear in associated pseudowire-specific documents for each PW 2218 type. 2220 If a sender includes a given PW type in the PW Capabilities List AVP, 2221 the sender assumes full responsibility for supporting that particular 2222 payload, such as any payload-specific AVPs, L2-Specific Sublayer, or 2223 control messages that may be defined in the appropriate companion 2224 document. 2226 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2227 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2228 (before hiding) of this AVP is 8 octets with one PW type specified, 2229 plus 2 octets for each additional PW type. 2231 Preferred Language (SCCRQ, SCCRP) 2233 The Preferred Language AVP, Attribute Type AVP-TBD-14, provides a 2234 method for an LCCE to indicate to the peer the language in which 2235 human-readable messages it sends SHOULD be composed. This AVP 2236 contains a single language tag or language range [RFC3066]. 2238 The Attribute Value field for this AVP has the following format: 2240 0 1 2 3 2241 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 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 | Preferred Language... (arbitrary number of octets) 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 The Preferred Language is the indicated number of octets representing 2247 the language tag or language range, encoded in the US-ASCII charset. 2249 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2250 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2251 (before hiding) of this AVP is 6 plus the length of the Preferred 2252 Language. 2254 5.4.4 Session Management AVPs 2256 Local Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI) 2258 The Local Session ID AVP (analogous to the Assigned Session ID in 2259 L2TPv2), Attribute Type AVP-TBA-5, contains the identifier being 2260 assigned to this session by the sender. 2262 The Attribute Value field for this AVP has the following format: 2264 0 1 2 3 2265 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 2266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2267 | Local Session ID | 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2270 The Local Session ID is a 4-octet non-zero unsigned integer. 2272 The Local Session ID AVP establishes the two identifiers used to 2273 multiplex and demultiplex sessions between two LCCEs. Each LCCE 2274 chooses any free value it desires, and sends it to the remote LCCE 2275 using this AVP. The remote LCCE MUST then send all data packets 2276 associated with this session using this value. Additionally, for all 2277 session-oriented control messages sent after this AVP is received 2278 (e.g. ICRP, ICCN, CDN, SLI, etc.), the remote LCCE MUST echo this 2279 value in the Remote Session ID AVP. 2281 Note that a Session ID value is unidirectional. Because each LCCE 2282 chooses its Session ID independent of its peer LCCE, the value does 2283 not have to match in each direction for a given session. 2285 See Section 4.1 for additional information about the Session ID. 2287 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2288 AVP SHOULD be 1 set to 1, but MAY vary (see Section 5.2). The Length 2289 (before hiding) of this AVP is 10. 2291 Remote Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI) 2293 The Remote Session ID AVP, Attribute Type AVP-TBA-6, contains the 2294 identifier that was assigned to this session by the peer. 2296 The Attribute Value field for this AVP has the following format: 2298 0 1 2 3 2299 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2301 | Remote Session ID | 2302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2304 The Remote Session ID is a 4-octet non-zero unsigned integer. 2306 The Remote Session ID AVP MUST be present in all session-level 2307 control messages. The AVP's value echoes the session identifier 2308 advertised by the peer via the Local Session ID AVP. It is the same 2309 value that will be used in all transmitted data messages by this side 2310 of the session. In most cases, this identifier is sufficient for the 2311 peer to look up session-level context for this control message. 2313 When a session-level control message must be sent to the peer before 2314 the Local Session ID AVP has been received, the value of the Remote 2315 Sesson ID AVP MUST be set to zero. Additionally, the Local Session 2316 ID AVP (sent in a previous control message for this session) MUST be 2317 included in the control message. The peer must then use the Local 2318 Session ID AVP to perform a reverse lookup to find its session 2319 context. Session-level control messages defined in this document 2320 that might be subject to a reverse lookup by a receiving peer include 2321 the CDN, WEN, and SLI. 2323 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2324 AVP SHOULD be set to 1, but MAY vary (see Section 5, but MAY vary 2325 (see Section 5.2). The Length (before hiding) of this AVP is 10. 2327 Assigned Cookie (ICRQ, ICRP, OCRQ, OCRP) 2329 The Assigned Cookie AVP, Attribute Type AVP-TBA-7, contains the 2330 Cookie value being assigned to this session by the sender. 2332 The Attribute Value field for this AVP has the following format: 2334 0 1 2 3 2335 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 2336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2337 | Assigned Cookie (32 or 64 bits) ... 2338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 The Assigned Cookie is a 4-octet or 8-octet random value. 2342 The Assigned Cookie AVP contains the value used to check the 2343 association of a received data message with the session identified by 2344 the Session ID. All data messages sent to a peer MUST use the 2345 Assigned Cookie sent by the peer in this AVP. The value's length (0, 2346 32, or 64 bits) is obtained by the Length of the AVP. 2348 A missing Assigned Cookie AVP or Assigned Cookie Value of zero length 2349 indicates that the Cookie field should not be present in any data 2350 packets sent to the LCCE sending this AVP. 2352 See Section 4.1 for additional information about the Assigned Cookie. 2354 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2355 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2356 (before hiding) of this AVP may be 6, 10, or 14 octets. 2358 Serial Number (ICRQ, OCRQ) 2360 The Serial Number AVP, Attribute Type 15, contains an identifier 2361 assigned by the LAC or LNS to this session. 2363 The Attribute Value field for this AVP has the following format: 2365 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 2366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2367 | Serial Number | 2368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 The Serial Number is a 32-bit value. 2372 The Serial Number is intended to be an easy reference for 2373 administrators on both ends of a control connection to use when 2374 investigating session failure problems. Serial Numbers should be set 2375 to progressively increasing values, which are likely to be unique for 2376 a significant period of time across all interconnected LNSs and LACs. 2378 Note that in RFC 2661, this value was referred to as the "Call Serial 2379 Number AVP". It serves the same purpose and has the same attribute 2380 value and composition. 2382 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2383 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2384 (before hiding) of this AVP is 10. 2386 Remote End ID (ICRQ, OCRQ) 2388 The Remote End ID AVP, Attribute Type AVP-TBA-8, contains an 2389 identifier used to bind L2TP sessions to a given circuit, interface, 2390 or bridging instance. It also may be used to detect session-level 2391 ties. 2393 The Attribute Value field for this AVP has the following format: 2395 0 1 2 3 2396 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 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 | Remote End Identifier ... (arbitrary number of octets) 2399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 The Remote End Identifier field is a variable-length field whose 2402 value is unique for a given LCCE peer, as described in Section 3.3. 2404 A session-level tie is detected if an LCCE receives an ICRQ or OCRQ 2405 with an End ID AVP whose value matches that which was just sent in an 2406 outgoing ICRQ or OCRQ to the same peer. If the two values match, an 2407 LCCE recognizes that a tie exists (e.g. both LCCEs are attempting to 2408 establish sessions for the same circuit). The tie is broken by the 2409 Session Tie Breaker AVP. 2411 By default, the LAC-LAC cross-connect application (see section 2412 2.0(b)) of L2TP over an IP network MUST utilize the Router ID AVP and 2413 Remote End ID AVP to associate a circuit to an L2TP session. Other 2414 AVPs MAY be used for LCCE or circuit identification as specified in 2415 companion documents. 2417 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2418 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2419 (before hiding) of this AVP is 6 plus the length of the Remote End 2420 Identifier value. 2422 Session Tie Breaker (ICRQ, OCRQ) 2424 The Session Tie Breaker AVP, Attribute Type TBD, is used to break 2425 ties when two peers concurrently attempt to establish a session for 2426 the same circuit. 2428 The Attribute Value field for this AVP has the following format: 2430 0 1 2 3 2431 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 2432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2433 | Session Tie Breaker Value ... 2434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2435 ... (64 bits) | 2436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 The Session Tie Breaker Value is an 8-octet random value that is used 2439 to choose a session when two LCCEs concurrently request a session for 2440 the same circuit. A tie is detected by examining the peer's identity 2441 (described in Section 3.3) plus the per-session shared value 2442 communicated via the End ID AVP. In the case of a tie, the recipient 2443 of an ICRQ or OCRQ must compare the received tie breaker value with 2444 the one that it sent earlier. The LCCE with the lower value "wins", 2445 and the "loser" MUST send a CDN with result code set to RC-TBA-1 (as 2446 defined in Section 5.4.2) to tear down the session it instigated. In 2447 the case in which a tie is detected, tie breakers are sent by both 2448 sides, and the tie breaker values are equal, both sides MUST discard 2449 their sessions and restart session negotiation with new random tie 2450 breaker values. 2452 If a tie is detected but only one side sends a Session Tie Breaker 2453 AVP, the session initiator that included the Session Tie Breaker AVP 2454 "wins". If neither side issues a tie breaker, then both sides MUST 2455 tear down the session. 2457 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this 2458 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length of 2459 this AVP is 14. 2461 Pseudowire Type (ICRQ, OCRQ) 2463 The Pseudowire Type (PW Type) AVP, Attribute Type AVP-TBA-10, 2464 indicates the L2 payload type of the packets that will be tunneled 2465 using this L2TP session. 2467 The Attribute Value field for this AVP has the following format: 2469 0 1 2470 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 | PW Type | 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2475 A peer MUST NOT request an incoming or outgoing call with a PW Type 2476 AVP specifying a value not advertised in the PW Capabilities List AVP 2477 it received during control connection establishment. Attempts to do 2478 so MUST result in the call being rejected via a CDN with the Result 2479 Code set to RC-TBA-2 (see Section 5.4.2). 2481 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2482 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2483 (before hiding) of this AVP is 8. 2485 L2-Specific Sublayer (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2487 The L2-Specific Sublayer AVP, Attribute Type AVP-TBA-11, indicates 2488 the presence and format of the L2-Specific Sublayer the sender of 2489 this AVP requires on all incoming data packets for this L2TP session. 2491 0 1 2492 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 | L2-Specific Sublayer Type | 2495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2497 The L2-Specific Sublayer Type is a 2-octet unsigned integer with the 2498 following values defined in this document: 2500 0 - There is no L2-Specific Sublayer present. 2501 1 - The default L2-Specific Sublayer (defined in Section 4.6) 2502 is used. 2504 If this AVP is received and has a value other than zero, the 2505 receiving LCCE MUST include the identified L2-Specific Sublayer in 2506 its outgoing data messages. If the AVP is not received, it is 2507 assumed that there is no sublayer present. 2509 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2510 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2511 (before hiding) of this AVP is 8. 2513 Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2515 The Data Sequencing AVP, Attribute Type AVP-TBA-12, indicates that 2516 the sender requires some or all of the data packets that it receives 2517 to be sequenced. 2519 The Attribute Value field for this AVP has the following format: 2521 0 1 2522 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2524 | Data Sequencing Level | 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2527 The Data Sequencing Level is a 2-octet unsigned integer indicating 2528 the degree of incoming data traffic that the sender of this AVP 2529 wishes to be marked with sequence numbers. 2531 The following values are valid data sequencing levels: 2533 0 - No incoming data packets require sequencing. 2534 1 - Only non-IP data packets require sequencing. 2535 2 - All incoming data packets require sequencing. 2537 If a data sequencing level of 0 is specified, there is no need to 2538 send packets with sequence numbers. If sequence numbers are sent, 2539 they will be ignored upon receipt. If no Data Sequencing AVP is 2540 received, a data sequencing level of 0 is assumed. 2542 If a data sequencing level of 1 is specified, only non-IP traffic 2543 carried within the tunneled L2 frame should have sequence numbers 2544 applied. Non-IP traffic here refers to any packets that cannot be 2545 classified as an IP packet within their respective L2 framing (i.e., 2546 a PPP control packet or NETBIOS frame encapsulated by Frame Relay 2547 before being tunneled). All traffic that can be classified as IP MUST 2548 be sent with no sequencing (e.g. the S bit in the L2-Specific 2549 Sublayer is set to zero). If a packet is unable to be classified at 2550 all (e.g. due to it being compressed or encrypted at layer 2) or if 2551 an implementation is unable to perform such classification within L2 2552 frames, all packets MUST be provided with sequence numbers 2553 (essentially falling back to a data sequencing level of 2). 2555 If a data sequencing level of 2 is specified, all traffic MUST be 2556 sequenced. 2558 Data sequencing may only be requested when there is an L2-Specific 2559 Sublayer present that can provide sequence numbers. If sequencing is 2560 requested without requesting a L2-Specific Sublayer AVP, the session 2561 MUST be disconnected with a Result Code of RC-TBA-3. 2563 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2564 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2565 (before hiding) of this AVP is 6. 2567 Tx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2569 The Tx Connect Speed BPS AVP, Attribute Type AVP-TBA-16, contains the 2570 speed of the facility chosen for the connection attempt. 2572 The Attribute Value field for this AVP has the following format: 2574 0 1 2 3 2575 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 2576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2577 | Connect Speed in bps... 2578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2579 ...Connect Speed in bps (64 bits) | 2580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2582 The Tx Connect Speed BPS is an 8-octet value indicating the speed in 2583 bits per second. A value of zero indicates that the speed is 2584 indeterminable or that there is no physical point-to-point link. 2586 When the optional Rx Connect Speed AVP is present, the value in this 2587 AVP represents the transmit connect speed from the perspective of the 2588 LAC (e.g. data flowing from the LAC to the remote system). When the 2589 optional Rx Connect Speed AVP is NOT present, the connection speed 2590 between the remote system and LAC is assumed to be symmetric and is 2591 represented by the single value in this AVP. 2593 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2594 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2595 (before hiding) of this AVP is 14. 2597 Rx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2599 The Rx Connect Speed AVP, Attribute Type AVP-TBA-17, represents the 2600 speed of the connection from the perspective of the LAC (e.g. data 2601 flowing from the remote system to the LAC). 2603 The Attribute Value field for this AVP has the following format: 2605 0 1 2 3 2606 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 2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2608 | Connect Speed in bps... 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 ...Connect Speed in bps (64 bits) | 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2613 Connect Speed BPS is an 8-octet value indicating the speed in bits 2614 per second. A value of zero indicates that the speed is 2615 indeterminable or that there is no physical point-to-point link. 2617 Presence of this AVP implies that the connection speed may be 2618 asymmetric with respect to the transmit connect speed given in the Tx 2619 Connect Speed AVP. 2621 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2622 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2623 (before hiding) of this AVP is 14. 2625 Physical Channel ID (ICRQ, ICRP, OCRP) 2627 The Physical Channel ID AVP, Attribute Type 25, contains the vendor- 2628 specific physical channel number used for a call. 2630 The Attribute Value field for this AVP has the following format: 2632 0 1 2 3 2633 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 2634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2635 | Physical Channel ID | 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2638 Physical Channel ID is a 4-octet value intended to be used for 2639 logging purposes only. 2641 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2642 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2643 (before hiding) of this AVP is 10. 2645 5.4.5 Circuit Status AVPs 2647 Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI) 2649 The Circuit Status AVP, Attribute Type AVP-TBA-13, indicates the 2650 initial status of or a status change in the circuit to which the 2651 session is bound. 2653 The Attribute Value field for this AVP has the following format: 2655 0 1 2656 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2658 | Reserved |N|A| 2659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 The A (Active) bit indicates whether the circuit is up/active/ready 2662 (1) or down/inactive/not-ready (0). 2664 The N (New) bit indicates whether the circuit status indication is 2665 for a new circuit (1) or an existing circuit (0). Links which have a 2666 similar mechanism available (e.g. Frame Relay) MUST map the setting 2667 of this bit to the associated signaling for that link. Otherwise, the 2668 New bit SHOULD still be set the first time the L2TP session is 2669 established after provisioning. 2671 The remaining bits are reserved for future use. Reserved bits MUST 2672 be set to 0 when sending and ignored upon receipt. 2674 The Circuit Status AVP is used to advertise whether a circuit or 2675 interface bound to an L2TP session is up and ready to send and/or 2676 receive traffic. Different circuit types have different names for 2677 status types. For example, HDLC primary and secondary stations refer 2678 to a circuit as being "Receive Ready" or "Receive Not Ready", while 2679 Frame Relay refers to a circuit as "Active" or "Inactive". This AVP 2680 adopts the latter terminology, though the concept remains the same 2681 regardless of the PW type for the L2TP session. 2683 In the simplest case, the circuit referred by this AVP is a single 2684 physical interface, port, or circuit depending on application and how 2685 the session was setup. The status indication in this AVP may then be 2686 used to provide simple ILMI interworking for a variety of circuit 2687 types. For virtual or multipoint interfaces, the Circuit Status AVP 2688 is still utilized, but effectively refers to the state of an internal 2689 structure or a logical set of circuits. Each PW-specific companion 2690 document MUST then specify precisely how this AVP is translated for 2691 each circuit type. 2693 If this AVP is received with a Not Active notification for a given 2694 L2TP session, all data traffic for that session MUST cease (or not 2695 begin) in the direction of the sender of the Circuit Status AVP until 2696 the circuit is advertised as Active. 2698 The Circuit Status MUST be advertised by this AVP in ICRQ, ICRP, 2699 OCRQ, and OCRP messages. Often, the circuit type will be marked 2700 Active when initiated, but MAY be advertised as Inactive, indicating 2701 that an L2TP session is to be created but that the interface or 2702 circuit is still not ready to pass traffic. The ICCN, OCCN, and SLI 2703 control messages all MAY contain this AVP to update the status of the 2704 circuit after establishment of the L2TP session is requested. 2706 If additional circuit status information is needed for a given PW 2707 type, PW-specific AVPs MUST be defined in a separate document for 2708 that information. This AVP is only for general circuit status 2709 information applicable to all circuit/interface types. 2711 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2712 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2713 (before hiding) of this AVP is 8. 2715 Circuit Errors (WEN) 2717 The Circuit Errors AVP, Attribute Type 34, conveys circuit error 2718 information to the peer. 2720 The Attribute Value field for this AVP has the following format: 2722 0 1 2 3 2723 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 2724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2725 | Reserved | 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 | Hardware Overruns | 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 | Buffer Overruns | 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2731 | Timeout Errors | 2732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2733 | Alignment Errors | 2734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2736 The following fields are defined: 2738 Reserved: 2 octets of Reserved data is present (providing longword 2739 alignment within the AVP of the following values). Reserved 2740 data MUST be zero on sending and ignored upon receipt. 2741 Hardware Overruns: Number of receive buffer overruns since call 2742 was established. 2743 Buffer Overruns: Number of buffer overruns detected since call was 2744 established. 2745 Timeout Errors: Number of timeouts since call was established. 2746 Alignment Errors: Number of alignment errors since call was 2747 established. 2749 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2750 AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length 2751 (before hiding) of this AVP is 32. 2753 6. Control Connection Protocol Specification 2755 The following control messages are used to establish, maintain, and 2756 tear down L2TP control connections. All data packets are sent in 2757 network order (high-order octets first). Any "reserved" or "empty" 2758 fields MUST be sent as 0 values to allow for protocol extensibility. 2760 The exchanges in which these messages are involved are outlined in 2761 Section 3.3. 2763 6.1 Start-Control-Connection-Request (SCCRQ) 2765 Start-Control-Connection-Request (SCCRQ) is a control message used to 2766 initiate a control connection between two LCCEs. It is sent by 2767 either the LAC or the LNS to begin the control connection 2768 establishment process. 2770 The following AVPs MUST be present in the SCCRQ: 2772 Message Type 2773 Host Name 2774 Router ID 2775 Assigned Control Connection ID 2776 Pseudowire Capabilities List 2778 The following AVPs MAY be present in the SCCRQ: 2780 Random Vector 2781 Nonce 2782 Message Digest 2783 Control Connection Tie Breaker 2784 Vendor Name 2785 Receive Window Size 2786 Preferred Language 2788 6.2 Start-Control-Connection-Reply (SCCRP) 2790 Start-Control-Connection-Reply (SCCRP) is the control message sent in 2791 reply to a received SCCRQ message. The SCCRP is used to indicate 2792 that the SCCRQ was accepted and establishment of the control 2793 connection should continue. 2795 The following AVPs MUST be present in the SCCRP: 2797 Message Type 2798 Host Name 2799 Router ID 2800 Assigned Control Connection ID 2801 Pseudowire Capabilities List 2803 The following AVPs MAY be present in the SCCRP: 2805 Random Vector 2806 Nonce 2807 Message Digest 2808 Vendor Name 2809 Receive Window Size 2810 Preferred Language 2812 6.3 Start-Control-Connection-Connected (SCCCN) 2814 Start-Control-Connection-Connected (SCCCN) is the control message 2815 sent in reply to an SCCRP. The SCCCN completes the control 2816 connection establishment process. 2818 The following AVP MUST be present in the SCCCN: 2820 Message Type 2822 The following AVP MAY be present in the SCCCN: 2824 Random Vector 2825 Message Digest 2827 6.4 Stop-Control-Connection-Notification (StopCCN) 2829 Stop-Control-Connection-Notification (StopCCN) is the control message 2830 sent by either LCCE to inform its peer that the control connection is 2831 being shut down and that the control connection should be closed. In 2832 addition, all active sessions are implicitly cleared (without sending 2833 any explicit session control messages). The reason for issuing this 2834 request is indicated in the Result Code AVP. There is no explicit 2835 reply to the message, only the implicit ACK that is received by the 2836 reliable control message delivery layer. 2838 The following AVPs MUST be present in the StopCCN: 2840 Message Type 2841 Result Code 2843 The following AVPs MAY be present in the StopCCN: 2845 Random Vector 2846 Message Digest 2847 Assigned Control Connection ID 2849 Note that the Assigned Control Connection ID MUST be present if the 2850 StopCCN is sent after an SCCRQ or SCCRP message has been sent. 2852 6.5 Hello (HELLO) 2854 The Hello (HELLO) message is an L2TP control message sent by either 2855 peer of a control connection. This control message is used as a 2856 "keepalive" for the control connection. See Section 4.2 for a 2857 description of the keepalive mechanism. 2859 HELLO messages are global to the control connection. The Session ID 2860 in a HELLO message MUST be 0. 2862 The following AVP MUST be present in the HELLO: 2864 Message Type 2866 The following AVP MAY be present in the HELLO: 2868 Random Vector 2869 Message Digest 2871 6.6 Incoming-Call-Request (ICRQ) 2873 Incoming-Call-Request (ICRQ) is the control message sent by an LCCE 2874 to a peer when an incoming call is detected (although the ICRQ may 2875 also be sent as a result of a local event). It is the first in a 2876 three-message exchange used for establishing a session via an L2TP 2877 control connection. 2879 The ICRQ is used to indicate that a session is to be established 2880 between an LCCE and a peer. The sender of an ICRQ provides the peer 2881 with parameter information for the session. However, the sender 2882 makes no demands about how the session is terminated at the peer 2883 (i.e. whether the L2 traffic is processed locally, forwarded, etc.). 2885 The following AVPs MUST be present in the ICRQ: 2887 Message Type 2888 Local Session ID 2889 Remote Session ID 2890 Serial Number 2891 Pseudowire Type 2892 Circuit Status 2894 The following AVPs MAY be present in the ICRQ: 2896 Random Vector 2897 Message Digest 2898 Assigned Cookie 2899 Remote End ID 2900 Session Tie Breaker 2901 L2-Specific Sublayer 2902 Data Sequencing 2903 Tx Connect Speed 2904 Rx Connect Speed 2905 Physical Channel ID 2907 6.7 Incoming-Call-Reply (ICRP) 2909 Incoming-Call-Reply (ICRP) is the control message sent by an LCCE in 2910 response to a received ICRQ. It is the second in the three-message 2911 exchange used for establishing sessions within an L2TP control 2912 connection. 2914 The ICRP is used to indicate that the ICRQ was successful and that 2915 the peer should establish (i.e. answer) the incoming call if it has 2916 not already done so. It also allows the sender to indicate specific 2917 parameters about the L2TP session. 2919 The following AVPs MUST be present in the ICRP: 2921 Message Type 2922 Local Session ID 2923 Remote Session ID 2924 Circuit Status 2926 The following AVPs MAY be present in the ICRP: 2928 Random Vector 2929 Message Digest 2930 Assigned Cookie 2931 L2-Specific Sublayer 2932 Data Sequencing 2933 Tx Connect Speed 2934 Rx Connect Speed 2935 Physical Channel ID 2937 6.8 Incoming-Call-Connected (ICCN) 2939 Incoming-Call-Connected (ICCN) is the control message sent by the 2940 LCCE that originally sent an ICRQ upon receiving an ICRP from its 2941 peer. It is the final message in the three-message exchange used for 2942 establishing L2TP sessions. 2944 The ICCN is used to indicate that the ICRP was accepted, that the 2945 call has been established, and that the L2TP session should move to 2946 the established state. It also allows the sender to indicate 2947 specific parameters about the established call (parameters that may 2948 not have been available at the time the ICRQ is issued). 2950 The following AVPs MUST be present in the ICCN: 2952 Message Type 2953 Local Session ID 2954 Remote Session ID 2956 The following AVPs MAY be present in the ICCN: 2958 Random Vector 2959 Message Digest 2960 L2-Specific Sublayer 2961 Data Sequencing 2962 Tx Connect Speed 2963 Rx Connect Speed 2964 Circuit Status 2966 6.9 Outgoing-Call-Request (OCRQ) 2968 Outgoing-Call-Request (OCRQ) is the control message sent by an LCCE 2969 to an LAC to indicate that an outbound call at the LAC is to be 2970 established based on specific destination information sent in this 2971 message. It is the first in a three-message exchange used for 2972 establishing a session and placing a call on behalf of the initiating 2973 LCCE. 2975 Note that a call may be any L2 connection requiring well-known 2976 destination information to be sent from an LCCE to an LAC. This call 2977 could be a dialup connection to the PSTN, an SVC connection, the IP 2978 address of another LCCE, or any other destination dictated by the 2979 sender of this message. 2981 The following AVPs MUST be present in the OCRQ: 2983 Message Type 2984 Local Session ID 2985 Remote Session ID 2986 Serial Number 2987 Pseudowire Type 2988 Circuit Status 2990 The following AVPs MAY be present in the OCRQ: 2992 Random Vector 2993 Message Digest 2994 Assigned Cookie 2995 Remote End ID 2996 Tx Connect Speed 2997 Rx Connect Speed 2998 Session Tie Breaker 2999 L2-Specific Sublayer 3000 Data Sequencing 3002 6.10 Outgoing-Call-Reply (OCRP) 3004 Outgoing-Call-Reply (OCRP) is the control message sent by an LAC to 3005 an LCCE in response to a received OCRQ. It is the second in a 3006 three-message exchange used for establishing a session within an L2TP 3007 control connection. 3009 OCRP is used to indicate that the LAC has been able to attempt the 3010 outbound call. The message returns any relevant parameters regarding 3011 the call attempt. Data MUST NOT be forwarded until the OCCN is 3012 received indicating that the call has been placed. 3014 The following AVPs MUST be present in the OCRP: 3016 Message Type 3017 Local Session ID 3018 Remote Session ID 3019 Circuit Status 3021 The following AVPs MAY be present in the OCRP: 3023 Random Vector 3024 Message Digest 3025 Assigned Cookie 3026 L2-Specific Sublayer 3027 Tx Connect Speed 3028 Rx Connect Speed 3029 Data Sequencing 3030 Physical Channel ID 3032 6.11 Outgoing-Call-Connected (OCCN) 3034 Outgoing-Call-Connected (OCCN) is the control message sent by an LAC 3035 to another LCCE after the OCRP and after the outgoing call has been 3036 completed. It is the final message in a three-message exchange used 3037 for establishing a session. 3039 OCCN is used to indicate that the result of a requested outgoing call 3040 was successful. It also provides information to the LCCE who 3041 requested the call about the particular parameters obtained after the 3042 call was established. 3044 The following AVPs MUST be present in the OCCN: 3046 Message Type 3047 Local Session ID 3048 Remote Session ID 3050 The following AVPs MAY be present in the OCCN: 3052 Random Vector 3053 Message Digest 3054 L2-Specific Sublayer 3055 Tx Connect Speed 3056 Rx Connect Speed 3057 Data Sequencing 3058 Circuit Status 3060 6.12 Call-Disconnect-Notify (CDN) 3062 The Call-Disconnect-Notify (CDN) is a control message sent by an LCCE 3063 to request disconnection of a specific session. Its purpose is to 3064 inform the peer of the disconnection and the reason for the 3065 disconnection. The peer MUST clean up any resources, and does not 3066 send back any indication of success or failure for such cleanup. 3068 The following AVPs MUST be present in the CDN: 3070 Message Type 3071 Result Code 3072 Local Session ID 3073 Remote Session ID 3075 The following AVP MAY be present in the CDN: 3077 Random Vector 3078 Message Digest 3080 6.13 WAN-Error-Notify (WEN) 3082 The WAN-Error-Notify (WEN) is a control message sent from an LAC to 3083 an LNS to indicate WAN error conditions. The counters in this 3084 message are cumulative. This message should only be sent when an 3085 error occurs, and not more than once every 60 seconds. The counters 3086 are reset when a new call is established. 3088 The following AVPs MUST be present in the WEN: 3090 Message Type 3091 Local Session ID 3092 Remote Session ID 3093 Circuit Errors 3095 The following AVP MAY be present in the WEN: 3097 Random Vector 3098 Message Digest 3100 6.14 Set-Link-Info (SLI) 3102 The Set-Link-Info control message is sent by an LCCE to convey link 3103 or circuit status change information regarding the circuit associated 3104 with this L2TP session. For example, if PPP renegotiates LCP at an 3105 LNS or between an LAC and a Remote System, or if a forwarded Frame 3106 Relay VC transitions to Active or Inactive at an LAC, an SLI message 3107 SHOULD be sent to indicate this event. Precise details of when the 3108 SLI is sent, what PW type-specific AVPs must be present, and how 3109 those AVPs should be interpreted by the receiving peer are outside 3110 the scope of this document. These details should be described in the 3111 associated pseudowire-specific documents that require use of this 3112 message. 3114 The following AVPs MUST be present in the SLI: 3116 Message Type 3117 Local Session ID 3118 Remote Session ID 3120 The following AVPs MAY be present in the SLI: 3122 Random Vector 3123 Message Digest 3124 Circuit Status 3126 6.15 Explicit-Acknowledgement (ACK) 3128 The Explicit Acknowledgement (ACK) message is used only to 3129 acknowledge receipt of a message or messages on the Control 3130 Connection (e.g. for purposes of updating Ns and Nr values). Receipt 3131 of this message does not trigger an event for the L2TP protocol state 3132 machine. 3134 A message received without any AVPs (including the Message Type AVP), 3135 is referred to as a Zero Length Body (ZLB) message, and serves the 3136 same function as the Explicit Acknowledgement. ZLB messages are only 3137 permitted when the Control Message Authentication defined in Section 3138 4.3 is not enabled. 3140 The following AVPs MAY be present in the ACK message: 3142 Message Type 3143 Message Digest 3145 7. Control Connection State Machines 3147 The state tables defined in this section govern the exchange of 3148 control messages defined in Section 6. Tables are defined for 3149 incoming call placement and outgoing call placement, as well as for 3150 initiation of the control connection itself. The state tables do not 3151 encode timeout and retransmission behavior, as this is handled in the 3152 underlying reliable control message delivery mechanism (see Section 3153 4.2). 3155 7.1 Malformed AVPs and Control Messages 3157 Receipt of an invalid or unrecoverable malformed control message 3158 SHOULD be logged appropriately and the control connection cleared to 3159 ensure recovery to a known state. The control connection may then be 3160 restarted by the initiator. 3162 An invalid control message is defined as (1) a message that contains 3163 a Message Type marked as mandatory (see Section 5.4.1) but that is 3164 unknown to the implementation, or (2) a control message that is 3165 received in the wrong state. 3167 Examples of malformed control messages include (1) a message that has 3168 an invalid value in its header, (2) a message that contains an AVP 3169 that is formatted incorrectly or whose value is out of range, and (3) 3170 a message that is missing a required AVP. A control message with a 3171 malformed header MUST be discarded. 3173 When possible, a malformed AVP should be considered in the same 3174 manner as an unrecognized AVP as described in Section 5.2. Thus, an 3175 attempt to inspect the M-bit SHOULD be made to determine the 3176 importance of the malformed AVP and thus the severity of the 3177 malformation to the entire control message. If the M-bit was able to 3178 be reasonably inspected within the malformed AVP and found to be 1, 3179 then as with an unrecognized AVP the associated Session or Control 3180 Connection MUST be shutdown. If the M-bit was inspected and found to 3181 be 0, the AVP MUST be ignored, assuming recovery from the AVP 3182 malformation is indeed possible. 3184 This policy must not be considered a license to send malformed AVPs, 3185 but rather, a guide towards how to handle an improperly formatted 3186 message if one is received. It is impossible to list all potential 3187 malformations of a given message and give advice for each. One 3188 example of a malformed AVP situation which should be recoverable, is 3189 if the Rx Connect Speed AVP is received with a length of 10 rather 3190 than 14, implying that the connect speed bits-per-second is being 3191 formatted in 4 octets rather than 8. If the Rx Connect Speed AVP did 3192 not have its M-bit set (which would typically be the case) this 3193 condition would not be considered catastrophic. As such, the control 3194 message should be accepted as if the AVP had not been present (with 3195 the exception of a local error message being logged). 3197 In several cases in the following tables, a protocol message is sent, 3198 and then a "clean up" occurs. Note that, regardless of the initiator 3199 of the control connection destruction, the reliable delivery 3200 mechanism must be allowed to run (see Section 4.2) before destroying 3201 the control connection. This permits the control connection 3202 management messages to be reliably delivered to the peer. 3204 Appendix B.1 contains an example of lock-step control connection 3205 establishment. 3207 7.2 Control Connection States 3209 The L2TP control connection protocol is not distinguishable between 3210 the two LCCEs but is distinguishable between the originator and 3211 receiver. The originating peer is the one that first initiates 3212 establishment of the control connection. (In a tie breaker 3213 situation, this is the winner of the tie.) Since either the LAC or 3214 the LNS can be the originator, a collision can occur. See the 3215 Control Connection Tie Breaker AVP in Section 5.4.3 for a description 3216 of this and its resolution. 3218 State Event Action New State 3219 ----- ----- ------ --------- 3220 idle Local open Send SCCRQ wait-ctl-reply 3221 request 3223 idle Receive SCCRQ, Send SCCRP wait-ctl-conn 3224 acceptable 3226 idle Receive SCCRQ, Send StopCCN, idle 3227 not acceptable clean up 3229 idle Receive SCCRP Send StopCCN, idle 3230 clean up 3232 idle Receive SCCCN Send StopCCN, idle 3233 clean up 3234 wait-ctl-reply Receive SCCRP, Send SCCCN, established 3235 acceptable send control-conn 3236 open event to 3237 waiting sessions 3239 wait-ctl-reply Receive SCCRP, Send StopCCN, idle 3240 not acceptable clean up 3242 wait-ctl-reply Receive SCCRQ, Send SCCRP, wait-ctl-conn 3243 lose tie breaker, Clean up losing 3244 SCCRQ acceptable connection 3246 wait-ctl-reply Receive SCCRQ, Send StopCCN, idle 3247 lose tie breaker, Clean up losing 3248 SCCRQ unacceptable connection 3250 wait-ctl-reply Receive SCCRQ, Send StopCCN for wait-ctl-reply 3251 win tie breaker losing connection 3253 wait-ctl-reply Receive SCCCN Send StopCCN, idle 3254 clean up 3256 wait-ctl-conn Receive SCCCN, Send control-conn established 3257 acceptable open event to 3258 waiting sessions 3260 wait-ctl-conn Receive SCCCN, Send StopCCN, idle 3261 not acceptable clean up 3263 wait-ctl-conn Receive SCCRP, Send StopCCN, idle 3264 SCCRQ clean up 3266 established Local open Send control-conn established 3267 request open event to 3268 (new call) waiting sessions 3270 established Administrative Send StopCCN, idle 3271 control-conn clean up 3272 close event 3274 established Receive SCCRQ, Send StopCCN, idle 3275 SCCRP, SCCCN clean up 3277 idle, Receive StopCCN Clean up idle 3278 wait-ctl-reply, 3279 wait-ctl-conn, 3280 established 3282 The states associated with an LCCE for control connection 3283 establishment are as follows: 3285 idle 3286 Both initiator and recipient start from this state. An initiator 3287 transmits an SCCRQ, while a recipient remains in the idle state 3288 until receiving an SCCRQ. 3290 wait-ctl-reply 3291 The originator checks to see if another connection has been 3292 requested from the same peer, and if so, handles the collision 3293 situation described in Section 5.4.3. 3295 wait-ctl-conn 3296 Awaiting an SCCCN. Upon receipt, the challenge response contained 3297 in the message is checked. The control connection is established 3298 if authentication succeeds; otherwise, it is torn down. 3300 established 3301 An established connection may be terminated by either a local 3302 condition or the receipt of a StopCCN. In the event of a local 3303 termination, the originator MUST send a StopCCN and clean up the 3304 control connection. If the originator receives a StopCCN, it MUST 3305 also clean up the control connection. 3307 7.3 Incoming Calls 3309 An ICRQ is generated by an LCCE, typically in response to an incoming 3310 call or a local event. Once the LCCE sends the ICRQ, it waits for a 3311 response from the peer. However, it may choose to postpone 3312 establishment of the call (e.g. answering the call, bringing up the 3313 circuit) until the peer has indicated with an ICRP that it will 3314 accept the call. The peer may choose not to accept the call if, for 3315 instance, there are insufficient resources to handle an additional 3316 session. 3318 If the peer chooses to accept the call, it responds with an ICRP. 3319 When the local LCCE receives the ICRP, it attempts to establish the 3320 call. A final call connected message, the ICCN, is sent from the 3321 local LCCE to the peer to indicate that the call states for both 3322 LCCEs should enter the established state. If the call is terminated 3323 before the peer can accept it, a CDN is sent by the local LCCE to 3324 indicate this condition. 3326 When a call transitions to a "disconnected" or "down" state, the call 3327 is cleared normally, and the local LCCE sends a CDN. Similarly, if 3328 the peer wishes to clear a call, it sends a CDN and cleans up its 3329 session. 3331 7.3.1 ICRQ Sender States 3333 State Event Action New State 3334 ----- ----- ------ --------- 3336 idle Call signal or Initiate local wait-control-conn 3337 ready to receive control-conn 3338 incoming conn open 3340 idle Receive ICCN, Clean up idle 3341 ICRP, CDN 3343 wait-control- Bearer line drop Clean up idle 3344 conn or local close 3345 request 3347 wait-control- control-conn-open Send ICRQ wait-reply 3348 conn 3350 wait-reply Receive ICRP, Send ICCN established 3351 acceptable 3353 wait-reply Receive ICRP, Send CDN, idle 3354 Not acceptable clean up 3356 wait-reply Receive ICRQ Send CDN, idle 3357 clean up 3359 wait-reply Receive ICRQ, Process as idle 3360 lose tie breaker ICRQ Recipient 3361 (Section 7.3.2) 3363 wait-reply Receive ICRQ, Send CDN wait-reply 3364 win tie breaker for losing 3365 session 3367 wait-reply Receive CDN, Clean up idle 3368 ICCN 3370 wait-reply Local close Send CDN, idle 3371 request clean up 3373 established Receive CDN Clean up idle 3374 established Receive ICRQ, Send CDN, idle 3375 ICRP, ICCN clean up 3377 established Local close Send CDN, idle 3378 request clean up 3380 The states associated with the ICRQ sender are as follows: 3382 idle 3383 The LCCE detects an incoming call on one of its interfaces (e.g. 3384 an analog PSTN line rings, or an ATM PVC is provisioned), or a 3385 local event occurs. The LCCE initiates its control connection 3386 establishment state machine and moves to a state waiting for 3387 confirmation of the existence of a control connection. 3389 wait-control-conn 3390 In this state, the session is waiting for either the control 3391 connection to be opened or for verification that the control 3392 connection is already open. Once an indication that the control 3393 connection has been opened is received, session control messages 3394 may be exchanged. The first of these messages is the ICRQ. 3396 wait-reply 3397 The ICRQ sender receives either (1) a CDN indicating the peer is 3398 not willing to accept the call (general error or do not accept) 3399 and moves back into the idle state, or (2) an ICRP indicating the 3400 call is accepted. In the latter case, the LCCE sends an ICCN and 3401 enters the established state. 3403 established 3404 Data is exchanged over the session. The call may be cleared by 3405 any of the following: 3406 + An event on the connected interface: The LCCE sends a CDN. 3407 + Receipt of a CDN: The LCCE cleans up, disconnecting the call. 3408 + A local reason: The LCCE sends a CDN. 3410 7.3.2 ICRQ Recipient States 3412 State Event Action New State 3413 ----- ----- ------ --------- 3414 idle Receive ICRQ, Send ICRP wait-connect 3415 acceptable 3417 idle Receive ICRQ, Send CDN, idle 3418 not acceptable clean up 3420 idle Receive ICRP Send CDN idle 3421 clean up 3423 idle Receive ICCN Clean up idle 3425 wait-connect Receive ICCN Prepare for established 3426 acceptable data 3428 wait-connect Receive ICCN Send CDN, idle 3429 not acceptable clean up 3431 wait-connect Receive ICRQ, Send CDN, idle 3432 ICRP clean up 3434 idle, Receive CDN Clean up idle 3435 wait-connect, 3436 established 3438 wait-connect Local close Send CDN, idle 3439 established request clean up 3441 established Receive ICRQ, Send CDN, idle 3442 ICRP, ICCN clean up 3444 The states associated with the ICRQ recipient are as follows: 3446 idle 3447 An ICRQ is received. If the request is not acceptable, a CDN is 3448 sent back to the peer LCCE, and the local LCCE remains in the idle 3449 state. If the ICRQ is acceptable, an ICRP is sent. The session 3450 moves to the wait-connect state. 3452 wait-connect 3453 The local LCCE is waiting for an ICCN from the peer. Upon receipt 3454 of the ICCN, the local LCCE moves to established state. 3456 established 3457 The session is terminated either by sending a CDN or by receiving 3458 a CDN from the peer. Clean up follows on both sides regardless of 3459 the initiator. 3461 7.4 Outgoing Calls 3463 Outgoing calls instruct an LAC to place a call. There are three 3464 messages for outgoing calls: OCRQ, OCRP, and OCCN. An LCCE first 3465 sends an OCRQ to an LAC to request an outgoing call. The LAC MUST 3466 respond to the OCRQ with an OCRP once it determines that the proper 3467 facilities exist to place the call and that the call is 3468 administratively authorized. Once the outbound call is connected, 3469 the LAC sends an OCCN to the peer indicating the final result of the 3470 call attempt. 3472 7.4.1 OCRQ Sender States 3474 State Event Action New State 3475 ----- ----- ------ --------- 3476 idle Local open Initiate local wait-control-conn 3477 request control-conn-open 3479 idle Receive OCCN, Clean up idle 3480 OCRP 3482 wait-control- control-conn-open Send OCRQ wait-reply 3483 conn 3485 wait-reply Receive OCRP, none wait-connect 3486 acceptable 3488 wait-reply Receive OCRP, Send CDN, idle 3489 not acceptable clean up 3491 wait-reply Receive OCCN Send CDN, idle 3492 clean up 3494 wait-reply Receive ICRQ, Process as idle 3495 lose tie breaker OCRQ Recipient 3496 (Section 7.4.2) 3498 wait-reply Receive ICRQ, Send CDN wait-reply 3499 win tie breaker for losing 3500 session 3502 wait-connect Receive OCCN none established 3504 wait-connect Receive OCRQ, Send CDN, idle 3505 OCRP clean up 3507 idle, Receive CDN Clean up idle 3508 wait-reply, 3509 wait-connect, 3510 established 3512 established Receive OCRQ, Send CDN, idle 3513 OCRP, OCCN clean up 3515 wait-reply, Local close Send CDN, idle 3516 wait-connect, request clean up 3517 established 3518 wait-control- Local close Clean up idle 3519 conn request 3521 The states associated with the OCRQ sender are as follows: 3523 idle, wait-control-conn 3524 When an outgoing call request is initiated, a control connection 3525 is created as described above, if not already present. Once the 3526 control connection is established, an OCRQ is sent to the LAC, and 3527 the session moves into the wait-reply state. 3529 wait-reply 3530 If a CDN is received, the session is cleaned up and returns to 3531 idle state. If an OCRP is received, the call is in progress, and 3532 the session moves to the wait-connect state. 3534 wait-connect 3535 If a CDN is received, the session is cleaned up and returns to 3536 idle state. If an OCCN is received, the call has succeeded, and 3537 the session may now exchange data. 3539 established 3540 If a CDN is received, the session is cleaned up and returns to 3541 idle state. Alternatively, if the LCCE chooses to terminate the 3542 session, it sends a CDN to the LAC, cleans up the session, and 3543 moves the session to idle state. 3545 7.4.2 OCRQ Recipient (LAC) States 3547 State Event Action New State 3548 ----- ----- ------ --------- 3549 idle Receive OCRQ, Send OCRP, wait-cs-answer 3550 acceptable Place call 3552 idle Receive OCRQ, Send CDN, idle 3553 not acceptable clean up 3555 idle Receive OCRP Send CDN, idle 3556 clean up 3558 idle Receive OCCN, Clean up idle 3559 CDN 3561 wait-cs-answer Call placement Send OCCN established 3562 successful 3564 wait-cs-answer Call placement Send CDN, idle 3565 failed clean up 3567 wait-cs-answer Receive OCRQ, Send CDN, idle 3568 OCRP, OCCN clean up 3570 established Receive OCRQ, Send CDN, idle 3571 OCRP, OCCN clean up 3573 wait-cs-answer, Receive CDN Clean up idle 3574 established 3576 wait-cs-answer, Local close Send CDN, idle 3577 established request clean up 3579 The states associated with the LAC for outgoing calls are as follows: 3581 idle 3582 If the OCRQ is received in error, respond with a CDN. Otherwise, 3583 place the call, send an OCRP, and move to the wait-cs-answer 3584 state. 3586 wait-cs-answer 3587 If the call is not completed or a timer expires while waiting for 3588 the call to complete, send a CDN with the appropriate error 3589 condition set, and go to idle state. If a circuit-switched 3590 connection is established, send an OCCN indicating success, and go 3591 to established state. 3593 established 3594 If the LAC receives a CDN from the peer, the call MUST be released 3595 via appropriate mechanisms, and the session cleaned up. If the 3596 call is disconnected because the circuit transitions to a 3597 "disconnected" or "down" state, the LAC MUST send a CDN to the 3598 peer and return to idle state. 3600 7.5 Termination of a Control Connection 3602 The termination of a control connection consists of either peer 3603 issuing a StopCCN. The sender of this message SHOULD wait a full 3604 control message retransmission cycle (e.g. 1 + 2 + 4 + 8 ... seconds) 3605 for the acknowledgment of this message before releasing the control 3606 information associated with the control connection. The recipient of 3607 this message should send an acknowledgment of the message to the 3608 peer, then release the associated control information. 3610 When to release a control connection is an implementation issue and 3611 is not specified in this document. A particular implementation may 3612 use whatever policy is appropriate for determining when to release a 3613 control connection. Some implementations may leave a control 3614 connection open for a period of time or perhaps indefinitely after 3615 the last session for that control connection is cleared. Others may 3616 choose to disconnect the control connection immediately after the 3617 last call on the control connection disconnects. 3619 8. Security Considerations 3621 This section addresses some of the security issues that L2TP 3622 encounters in its operation. 3624 8.1 Control Connection Endpoint and Message Security 3626 If a shared secret (password) exists between two LCCEs, it may be 3627 used to perform a mutual authentication between the two LCCEs, and 3628 construct an authentication and integrity check of arriving L2TP 3629 Control Messages. This mechanism is built-in to L2TPv3, and is 3630 described in section 4.3 and in the definition of the Message Digest 3631 and Nonce AVPs in section 5.4.1. 3633 This control channel security mechanism provides for (1) mutual 3634 endpoint authentication, and (2) individual control message integrity 3635 and authenticity checking. Mutual endpoint authentication ensures 3636 that an L2TPv3 Control Connection is only established between two 3637 endpoints that are configured with the proper password. The 3638 individual control message and integrity check guards against 3639 accidental or intentional packet corruption (i.e., those caused by a 3640 control message spoofing or man-in-the-middle attack). 3642 The shared secret that is used for all Control Connection, Control 3643 Message and AVP security features defined in this document never 3644 requires the shared secret to be sent in the clear between L2TP 3645 tunnel endpoints. 3647 8.2 Data Packet Spoofing 3649 Packet spoofing for any type of Virtual Private Network (VPN) 3650 protocol is of particular concern as insertion of carefully 3651 constructed rogue packets into the VPN transit network could result 3652 in a violation of VPN traffic separation, leaking data into a 3653 customer VPN. This is complicated by the fact that it may be 3654 particularly difficult for the operator of the VPN to even be aware 3655 that it has become a point of transit into or between customer VPNs. 3657 L2TPv3 provides traffic separation for its VPNs via a 32-bit Session 3658 ID in the L2TPv3 Header. When present, the L2TPv3 Cookie (described 3659 in section 4.1), provides an additional check to ensure that an 3660 arriving packet is intended for the identified Session. Thus, use of 3661 a Cookie with the Session ID provides an extra guarantee that the 3662 Session ID lookup was performed properly and that the Session ID 3663 itself was not corrupted in transit. 3665 In the presence of a blind packet spoofing attack, the Cookie may 3666 also provide security against inadvertent leaking of frames into a 3667 customer VPN. To illustrate the type of security that it is provided 3668 in this case, consider comparing the validation of a 64-bit cookie in 3669 the L2TPv3 header to permitting packets that match a given source and 3670 destination IP address. Both the source and destination IP address 3671 validation and Cookie validation consist of a fast check on cleartext 3672 header information on all arriving packets. However, since L2TPv3 3673 uses its own value, it removes the requirement for one to maintain a 3674 list of (potentially several) permitted or denied IP addresses, and 3675 to guard knowledge of the permitted IP addresses from hackers who may 3676 obtain and spoof them. Further, it is far easier to change an L2TPv3 3677 Cookie than an IP address if it is compromised, and a 3678 cryptographically random [RFC1750] value is far less likely to be 3679 discovered by brute-force attacks compared to an IP address. 3681 For protection against brute-force, blind, insertion attacks, a 64- 3682 bit Cookie MUST be used with all sessions. A 32 bit Cookie is 3683 vulnerable to brute-force guessing at high packet rates, and as such 3684 should not be considered an effective barrier to blind insertion 3685 attacks (it is still useful, however, as an additional verification 3686 of a successful Session ID lookup). The Cookie provides no protection 3687 against a sophisticated man-in-the-middle attacker who can sniff and 3688 correlate captured data between nodes for use in a coordinated 3689 attack. 3691 The Assigned Cookie AVP is used to signal the value and size of the 3692 Cookie that must be present in all data packets for a given Session. 3693 Each Assigned Cookie MUST be selected in a cryptographically random 3694 manner [RFC1750] such that a series of Assigned Cookies does not 3695 provide any indication of what a future Cookie will be. 3697 The L2TPv3 Cookie must not be regarded as a substitute for security 3698 such as that of IPsec when operating over an open or untrusted 3699 network where packets may be sniffed, decoded and correlated for use 3700 in a coordinated attack. See section 4.1.3 for more information on 3701 running L2TP over IPsec. 3703 9. Internationalization Considerations 3705 The Host Name and Vendor Name AVPs are not internationalized. The 3706 Vendor Name AVP, although intended to be human-readable, would seem 3707 to fit in the category of "globally visible names" [RFC2277] and so 3708 is represented in US-ASCII. 3710 The Preferred Language AVP is not mandatory. If an LCCE does not 3711 signify a language preference by the inclusion of this AVP in the 3712 SCCRQ or SCCRP, the Preferred Language AVP is unrecognized, or the 3713 requested language is not supported by the peer LCCE, the default 3714 language [RFC2277] MUST be used for all internationalized strings 3715 sent by the peer. 3717 10. IANA Considerations 3719 This document defines a number of "magic" numbers to be maintained by 3720 the IANA. This section explains the criteria to be used by the IANA 3721 to assign additional numbers in each of these lists. The following 3722 subsections describe the assignment policy for the namespaces defined 3723 elsewhere in this document. 3725 Sections 10.1 - 10.3 are requests for new values already managed by 3726 IANA according to [RFC3438]. 3728 The remaining sections are for new registries to be added to the 3729 existing L2TP registry and maintained by IANA accordingly. 3731 10.1 Control Message Attribute Value Pairs (AVPs) 3733 This number space is managed by IANA as per [RFC3438]. 3735 New AVPs requiring assignment in this document are encoded with 3736 "AVP-TBA-x," where "x" is 1, 2, 3... 3738 A summary of the new AVPs follows: 3740 Control Message Attribute Value Pairs 3742 Attribute 3743 Type Description 3744 --------- ------------------ 3746 AVP-TBA-0 Extended Vendor ID AVP 3747 AVP-TBA-1 Message Digest 3748 AVP-TBA-2 Router ID 3749 AVP-TBA-3 Assigned Control Connection ID 3750 AVP-TBA-4 Pseudowire Capabilities List 3751 AVP-TBA-5 Local Session ID 3752 AVP-TBA-6 Remote Session ID 3753 AVP-TBA-7 Assigned Cookie 3754 AVP-TBA-8 Remote End ID 3755 AVP-TBA-9 Application Code 3756 AVP-TBA-10 Pseudowire Type 3757 AVP-TBA-11 L2-Specific Sublayer 3758 AVP-TBA-12 Data Sequencing 3759 AVP-TBA-13 Circuit Status 3760 AVP-TBA-14 Preferred Language 3761 AVP-TBA-15 Control Message Authentication Nonce 3762 AVP-TBA-16 Tx Connect Speed 3763 AVP-TBA-17 Rx Connect Speed 3765 10.2 Message Type AVP Values 3767 This number space is managed by IANA as per [RFC3438]. There is one 3768 new message type, defined in section 3.1, necessary to be allocated 3769 for this specification: 3771 Message Type AVP (Attribute Type 0) Values 3772 ------------------------------------------ 3774 Control Connection Management 3776 TBA-M1 (ACK) Explicit Acknowledgement 3778 10.3 Result Code AVP Values 3780 This number space is managed by IANA as per [RFC3438]. 3782 New Result Code values for the CDN message are defined in section 3783 5.4. Following is a summary: 3785 Result Code AVP (Attribute Type 1) Values 3786 ----------------------------------------- 3788 General Error Codes 3790 RC-TBA-1 - Session not established due to losing 3791 tie breaker (L2TPv3). 3792 RC-TBA-2 - Session not established due to unsupported 3793 PW type (L2TPv3). 3794 RC-TBA-3 - Session not established, sequencing required 3795 without valid L2-Specific Sublayer (L2TPv3). 3797 There are a few cases in Section 5 where these values are referred to 3798 directly within the document text with the RC-TBA-x format. The 3799 assigned values should be inserted within the text for these cases. 3801 10.4 AVP Header Bits 3803 This is a new registry for IANA to maintain. 3805 Leading Bits of the L2TP AVP Header 3806 ----------------------------------- 3808 There six bits at the beginning of the L2TP AVP header. New bits are 3809 assigned via Standards Action [RFC2434]. 3811 Bit 0 - Mandatory Bit, "M-bit" 3812 Bit 1 - Hidden Bit, "H-bit" 3813 Bit 2 - Reserved 3814 Bit 3 - Reserved 3815 Bit 4 - Reserved 3816 Bit 5 - Reserved 3818 10.5 L2TP Control Message Header Bits 3820 This is a new registry for IANA to maintain. 3822 Leading Bits of the L2TP Control Message Header 3823 ----------------------------------------------- 3825 There are 12 bits at the beginning of the L2TP Control Message 3826 Header. Reserved bits should only be defined by Standard 3827 Action [RFC2434]. 3829 Bit 0 - Message Type, "T-bit" 3830 Bit 1 - Length Field is Present, "L-bit" 3831 Bit 2 - Reserved 3832 Bit 3 - Reserved 3833 Bit 4 - Sequence Numbers Present, "S-bit" 3834 Bit 5 - Reserved 3835 Bit 6 - Offset Field is Present 3836 Bit 7 - Priority Bit, "P-bit" 3837 Bit 8 - Reserved 3838 Bit 9 - Reserved 3839 Bit 10 - Reserved 3840 Bit 11 - Reserved 3842 10.6 Pseudowire Types 3844 This is a new registry for IANA to maintain, there are no values 3845 assigned within this document. 3847 L2TPv3 Pseudowire Types 3848 ----------------------- 3849 The Pseudowire Type (PW Type, Section 5.4) is a two-octet value used 3850 in the Pseudowire Type AVP and Pseudowire Capabilities List AVP 3851 defined in Section 5.4.3. 0 to 32767 are assignable by Expert Review 3852 [RFC2434], 32768 to 65535 by a First Come First Served policy 3853 [RFC2434]. There are no specific pseudowire types assigned within 3854 this document. Each pseudowire-specific document must allocate its 3855 own PW types from IANA as necessary. 3857 10.7 Circuit Status Bits 3859 This is a new registry for IANA to maintain. 3861 Circuit Status Bits 3862 ------------------- 3864 The Circuit Status field is a 16 bit mask, with the two high order 3865 bits assigned. Additional bits may be assigned by IETF Consensus 3866 [RFC2434]. 3868 Bit 15 - A (Active) bit 3869 Bit 16 - N (New) bit 3871 10.8 Default L2-Specific Sublayer bits 3873 This is a new registry for IANA to maintain. 3875 Default L2-Specific Sublayer bits 3876 --------------------------------- 3878 The Default L2 Specific Sublayer contains 8 bits in the low-order 3879 portion of the header. Reserved bits may be assigned by IETF 3880 Consensus [RFC2434]. 3882 Bit 0 - Reserved 3883 Bit 1 - S (Sequence) bit 3884 Bit 2 - Reserved 3885 Bit 3 - Reserved 3886 Bit 4 - Reserved 3887 Bit 5 - Reserved 3888 Bit 6 - Reserved 3889 Bit 7 - Reserved 3891 10.9 L2-Specific Sublayer Type 3893 This is a new registry for IANA to maintain. 3895 L2-Specific Sublayer Type 3896 ------------------------- 3897 The L2-Specific Sublayer Type is a 2 octet unsigned integer. 3898 Additional values may be assigned by Expert Review [RFC2434]. 3900 0 - No L2-Specific Sublayer 3901 1 - Default L2-Specific Sublayer present 3903 10.10 Data Sequencing Level 3905 This is a new registry for IANA to maintain. 3907 Data Sequencing Level 3908 --------------------- 3910 The Data Sequencing Level is a 2 octet unsigned integer 3911 Additional values may be assigned by Expert Review [RFC2434]. 3913 0 - No incoming data packets require sequencing. 3914 1 - Only non-IP data packets require sequencing. 3915 2 - All incoming data packets require sequencing. 3917 11. References 3919 11.1 Normative References 3921 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 3922 Protocol (CHAP)", RFC 1994, August 1996. 3924 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3925 Requirement Levels", BCP 14, RFC 2119, March 1997. 3927 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 3928 Languages", BCP 18, RFC 2277, January 1998. 3930 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3931 IANA Considerations section in RFCs", BCP 26, RFC 2434, 3932 October 1998. 3934 [RFC2661] Townsley, W., et al., "Layer Two Tunneling Layer Two 3935 Tunneling Protocol (L2TP)", RFC 2661, August 1999. 3937 [RFC2865] Rigney, C., Rubens, A., Simpson, W., and Willens, S., 3938 "Remote Authentication Dial In User Service (RADIUS)", 3939 RFC 2865, June 2000. 3941 [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", 3942 RFC 3066, January 2001. 3944 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and Booth, S., 3945 "Securing L2TP using IPsec", RFC 3193, November 2001. 3947 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 3948 RFC 3629, November 2003 3950 11.2 Informative References 3952 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 3953 STD 13, RFC 1034, November 1987. 3955 [RFC1191] Mogul, J. C. et al, "Path MTU Discovery", RFC 1191, 3956 November 1990 3958 [RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, 3959 04/16/1992 3961 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 3962 RFC 1661, July 1994. 3964 [RFC1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, 3965 RFC 1700, October 1994. See also: 3966 http://www.iana.org/numbers.html. 3968 [RFC1750] D. Eastlake III, S. Crocker, J. Schiller, "Randomness 3969 Recommendations for Security", RFC 1750, December 1994 3971 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 3972 RFC 1958, June 1996. 3974 [RFC1981] McCann, J. et al, "Path MTU Discovery for IP version 3975 6", RFC 1981, August 1996 3977 [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, 3978 January 1997. 3980 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 3981 for Message Authentication", RFC 2104, February 1997 3983 [RFC2138] Rigney, C., Rubens, A., Simpson, W., and Willens, S., 3984 "Remote Authentication Dial In User Service (RADIUS)", 3985 RFC 2138, April 1997. 3987 [RFC2341] Valencia, A., Littlewood, M., and Kolar, T., 3988 "Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341, 3989 May 1998. 3991 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 3992 Internet Protocol", RFC 2401, November 1998. 3994 [RFC2581] Allman, M., Paxson, V., Stevens, W., "TCP Congestion 3995 Control", RFC 2581, April 1999 3997 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., 3998 and Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", 3999 RFC 2637, July 1999. 4001 [RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for 4002 Literal IPv6 Addresses in URL's", RFC 2732, December 1999 4004 [RFC2809] Aboba, B., and Zorn, G., "Implementation of L2TP Compulsory 4005 Tunneling via RADIUS", RFC 2809, April 2000. 4007 [RFC3070] Rawat, V., Tio, R., Nanji, S., and Verma, R., 4008 "Layer Two Tunneling Protocol (L2TP) over Frame Relay", 4009 RFC 3070, February 2001. 4011 [RFC3355] Singh, A., Turner, R., Tio, R., Nanji, S., "Layer Two 4012 Tunnelling Protocol (L2TP) Over ATM Adaptation 4013 Layer 5 (AAL5)", RFC 3355, August 2002 4015 [KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network 4016 Security: Private Communications in a Public World", 4017 Prentice Hall, March 1995, ISBN 0-13-061466-1. 4019 [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I: The 4020 Protocols", Addison-Wesley Publishing Company, Inc., 4021 March 1996, ISBN 0-201-63346-9. 4023 12. Editors' Addresses 4025 Jed Lau 4026 cisco Systems 4027 170 W. Tasman Drive 4028 San Jose, CA 95134 4029 jedlau@cisco.com 4031 W. Mark Townsley 4032 cisco Systems 4033 mark@townsley.net 4034 Ignacio Goyret 4035 Lucent Technologies 4036 igoyret@lucent.com 4038 13. Acknowledgments 4040 Many of the protocol constructs were originally defined in, and the 4041 text of this document began with, RFC 2661, "L2TPv2". RFC 2661 4042 authors are W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn and 4043 B. Palter. 4045 The basic concept for L2TP and many of its protocol constructs were 4046 adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these 4047 drafts are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, 4048 W. Verthein, J. Taarud, W. Little, and G. Zorn. 4050 Danny Mcpherson and Suhail Nanji published the first "L2TP Service 4051 Type" draft which defined the use of L2TP for tunneling of various L2 4052 payload types (initially, Ethernet and Frame Relay). 4054 The team for splitting RFC 2661 into this base document and the 4055 companion PPP document consisted of Ignacio Goyret, Jed Lau, Bill 4056 Palter, Mark Townsley, and Madhvi Verma. Skip Booth also provided 4057 very helpful review and comment. 4059 Some constructs of L2TPv3 were based in part on UTI (Universal 4060 Transport Interface), which was originally conceived by Peter 4061 Lothberg and Tony Bates. 4063 Stewart Bryant and Simon Barber provided valuable input for the 4064 L2TPv3 over IP header. 4066 Juha Heinanen provided helpful review in the early stages of this 4067 effort. 4069 Jan Vilhuber, Scott Fluhrer, David McGrew, Scott Wainner, Skip Booth 4070 and Maria Dos Santos contributed to the Control Message and 4071 Authentication Mechanism as well as general discussions of security. 4073 James Carlson, Thomas Narten, Maria Dos Santos, Steven Bellovin, Ted 4074 Hardie and Pekka Savola, provided very helpful review of the final 4075 versions of text. 4077 Russ Housley provided valuable review and comment on security, 4078 particularly with respect to the control message authentication 4079 mechanisms. 4081 Pekka Savola contributed to proper alignment with IPv6 and inspired 4082 much of section 4.1.4 on fragmentation. 4084 Aside of his original influence and co-authorship of RFC2661, Glen 4085 Zorn helped get all of the language and character references straight 4086 in this document. 4088 A number of people provided valuable input and effort for RFC2661, on 4089 which this document was based: 4091 John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, 4092 Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and 4093 review at the 43rd IETF in Orlando, FL, which led to improvement of 4094 the overall readability and clarity of RFC 2661. 4096 Thomas Narten provided a great deal of critical review and 4097 formatting. He wrote the first version of the IANA Considerations 4098 section. 4100 Dory Leifer made valuable refinements to the protocol definition of 4101 L2TP and contributed to the editing of early drafts leading to RFC 4102 2661. 4104 Steve Cobb and Evan Caves redesigned the state machine tables. 4106 Barney Wolff provided a great deal of design input on the original 4107 endpoint authentication mechanism. 4109 Appendix A: Control Slow Start and Congestion Avoidance 4111 Although each side has indicated the maximum size of its receive 4112 window, it is recommended that a slow start and congestion avoidance 4113 method be used to transmit control packets. The methods described 4114 here are based upon the TCP congestion avoidance algorithm as 4115 described in section 21.6 of TCP/IP Illustrated, Volume I, by W. 4116 Richard Stevens [STEVENS] (this algorithm is also described in 4117 [RFC2581]). 4119 Slow start and congestion avoidance make use of several variables. 4120 The congestion window (CWND) defines the number of packets a sender 4121 may send before waiting for an acknowledgment. The size of CWND 4122 expands and contracts as described below. Note, however, that CWND 4123 is never allowed to exceed the size of the advertised window obtained 4124 from the Receive Window AVP. (In the text below, it is assumed any 4125 increase will be limited by the Receive Window Size.) The variable 4126 SSTHRESH determines when the sender switches from slow start to 4127 congestion avoidance. Slow start is used while CWND is less than 4128 SSHTRESH. 4130 A sender starts out in the slow start phase. CWND is initialized to 4131 one packet, and SSHTRESH is initialized to the advertised window 4132 (obtained from the Receive Window AVP). The sender then transmits 4133 one packet and waits for its acknowledgment (either explicit or 4134 piggybacked). When the acknowledgment is received, the congestion 4135 window is incremented from one to two. During slow start, CWND is 4136 increased by one packet each time an ACK (explicit ACK message or 4137 piggybacked) is received. Increasing CWND by one on each ACK has the 4138 effect of doubling CWND with each round trip, resulting in an 4139 exponential increase. When the value of CWND reaches SSHTRESH, the 4140 slow start phase ends and the congestion avoidance phase begins. 4142 During congestion avoidance, CWND expands more slowly. Specifically, 4143 it increases by 1/CWND for every new ACK received. That is, CWND is 4144 increased by one packet after CWND new ACKs have been received. 4145 Window expansion during the congestion avoidance phase is effectively 4146 linear, with CWND increasing by one packet each round trip. 4148 When congestion occurs (indicated by the triggering of a 4149 retransmission) one-half of the CWND is saved in SSTHRESH, and CWND 4150 is set to one. The sender then reenters the slow start phase. 4152 Appendix B: Control Message Examples 4154 B.1: Lock-Step Control Connection Establishment 4156 In this example, an LCCE establishes a control connection, with the 4157 exchange involving each side alternating in sending messages. This 4158 example shows the final acknowledgment explicitly sent within an ACK 4159 message. An alternative would be to piggyback the acknowledgment 4160 within a message sent as a reply to the ICRQ or OCRQ that will likely 4161 follow from the side that initiated the control connection. 4163 LCCE A LCCE B 4164 ------ ------ 4165 SCCRQ -> 4166 Nr: 0, Ns: 0 4167 <- SCCRP 4168 Nr: 1, Ns: 0 4169 SCCCN -> 4170 Nr: 1, Ns: 1 4171 <- ACK 4172 Nr: 2, Ns: 1 4174 B.2: Lost Packet with Retransmission 4176 An existing control connection has a new session requested by LCCE A. 4177 The ICRP is lost and must be retransmitted by LCCE B. Note that loss 4178 of the ICRP has two effects: It not only keeps the upper level state 4179 machine from progressing, but also keeps LCCE A from seeing a timely 4180 lower level acknowledgment of its ICRQ. 4182 LCCE A LCCE B 4183 ------ ------ 4184 ICRQ -> 4185 Nr: 1, Ns: 2 4186 (packet lost) <- ICRP 4187 Nr: 3, Ns: 1 4189 (pause; LCCE A's timer started first, so fires first) 4191 ICRQ -> 4192 Nr: 1, Ns: 2 4194 (Realizing that it has already seen this packet, 4195 LCCE B discards the packet and sends an ACK message) 4197 <- ACK 4198 Nr: 3, Ns: 2 4200 (LCCE B's retransmit timer fires) 4202 <- ICRP 4203 Nr: 3, Ns: 1 4204 ICCN -> 4205 Nr: 2, Ns: 3 4207 <- ACK 4208 Nr: 4, Ns: 2 4210 Appendix C: Processing Sequence Numbers 4212 The Default L2-Specific Sublayer, defined in Section 4.6, provides a 4213 24-bit field for sequencing of data packets within an L2TP session. 4214 L2TP data packets are never retransmitted, so this sequence is used 4215 only to detect packet order, duplicate packets, or lost packets. 4217 The 24-bit Sequence Number field of the Default L2-Specific Sublayer 4218 contains a packet sequence number for the associated session. Each 4219 sequenced data packet that is sent must contain the sequence number, 4220 incremented by one, of the previous sequenced packet sent on a given 4221 L2TP session. Upon receipt, any packet with a sequence number equal 4222 to or greater than the current expected packet (the last received 4223 in-order packet plus one) should be considered "new" and accepted. 4224 All other packets are considered "old" or "duplicate" and discarded. 4225 Note that the 24-bit sequence number space includes zero as a valid 4226 sequence number (as such, it may be implemented with a masked 32-bit 4227 counter if desired). All new sessions MUST begin sending sequence 4228 numbers at zero. 4230 Larger or smaller sequence number fields are possible with L2TP if an 4231 alternative format to the Default L2-Specific Sublayer defined in 4232 this document is used. While 24 bits may be adequate in a number of 4233 circumstances, a larger sequence number space will be less 4234 susceptible to sequence number wrapping problems for very high 4235 session data rates across long dropout periods. The sequence number 4236 processing recommendations below should hold for any size sequence 4237 number field. 4239 When detecting whether a packet sequence number is "greater" or 4240 "less" than a given sequence number value, wrapping of the sequence 4241 number must be considered. This is typically accomplished by keeping 4242 a window of sequence numbers beyond the current expected sequence 4243 number for determination of whether a packet is "new" or not. The 4244 window may be sized based on the link speed and sequence number space 4245 and SHOULD be configurable with a default equal to one half the size 4246 of the available number space (e.g. 2^(n-1), where n is the number of 4247 bits available in the sequence number). 4249 Upon receipt, packets which exactly match the expected sequence 4250 number are processed immediately and the next expected sequence 4251 number incremented. Packets that fall within the window for new 4252 packets may either be processed immediately and the next expected 4253 sequence number updated to one plus that received in the new packet, 4254 or held for a very short period of time in hopes of receiving the 4255 missing packet(s). This 'very short period' should be configurable, 4256 with a default corresponding to a time lapse which is at least an 4257 order of magnitude less than the retransmission timeout periods of 4258 higher layer protocols such as TCP. 4260 For typical transient packet mis-orderings, dropping out-of-order 4261 packets alone should suffice and generally requires far less 4262 resources than actively reordering packets within L2TP. An exception 4263 is a case where a pair of packet fragments are persistently 4264 retransmitted and sent out-of-order. For example, if an IP packet has 4265 been fragmented into a very small packet followed by a very large 4266 packet before being tunneled by L2TP, it is possible (though 4267 admittedly wrong) that the two resulting L2TP packets may be 4268 consistently mis-ordered by the PSN in transit between L2TP nodes. If 4269 sequence numbers were being enforced at the receiving node without 4270 any buffering of out-of-order packets, then the fragmented IP packet 4271 may never reach its destination. It may be worth noting here that 4272 this condition is true for any tunneling mechanism of IP packets 4273 which include sequence number checking on receipt (i.e. GRE 4275 [RFC2890]). 4277 Utilization of a Data Sequencing Level (see Section 5.4.3) of 1 (only 4278 non-IP data packets require sequencing) allows IP data packets being 4279 tunneled by L2TP to not utilize sequence numbers, while utilizing 4280 sequence numbers and enforcing packet order for any remaining non-IP 4281 data packets. Depending on the requirements of the link-layer being 4282 tunneled, and the network data traversing the data-link, this is 4283 sufficient in many cases to enforce packet order on frames which 4284 require it (such as end-to-end data-link control messages), while not 4285 on IP packets which are known to be resilient to packet reordering. 4287 If a large number of packets (e.g. more than one new packet window) 4288 are dropped due to an extended outage, or loss of sequence number 4289 state on one side of the connection (perhaps as part of a forwarding 4290 plane reset or failover to a standby node), it is possible that a 4291 large number of packets will be sent in-order, but be wrongly 4292 detected by the peer as out-of-order. This can be generally 4293 characterized for a window size, w, sequence number space, s, and 4294 number of packets lost in transit between L2TP endpoints, p, as 4295 follows: 4297 If s > p > w, then an additional (s - p) packets that were otherwise 4298 received in-order, will be incorrectly classified as out-of-order and 4299 dropped. Thus, for a sequence number space, s = 128, window size, w = 4300 64, and number of lost packets, p = 70; 128 - 70 = 58 additional 4301 packets would be dropped after the outage until the sequence number 4302 wrapped back to the current expected next sequence number. 4304 To mitigate this additional packet loss, one MUST inspect the 4305 sequence numbers of packets dropped due to being classified as "old" 4306 and reset the expected sequence number accordingly. This may be 4307 accomplished by counting the number of "old" packets dropped that 4308 were in sequence among themselves and upon reaching a threshold, 4309 resetting the next expected sequence number to that seen in the 4310 arriving data packets. Packet timestamps may also be used as an 4311 indicator to reset the expected sequence number by detecting a period 4312 of time over which "old" packets have been received in-sequence. The 4313 ideal thresholds will vary depending on link speed, sequence number 4314 space, and link tolerance to out-of-order packets, and MUST be 4315 configurable. 4317 Intellectual Property Statement 4319 The IETF takes no position regarding the validity or scope of any 4320 Intellectual Property Rights or other rights that might be claimed to 4321 pertain to the implementation or use of the technology described in 4322 this document or the extent to which any license under such rights 4323 might or might not be available; nor does it represent that it has 4324 made any independent effort to identify any such rights. Information 4325 on the procedures with respect to rights in RFC documents can be 4326 found in BCP 78 and BCP 79. 4328 Copies of IPR disclosures made to the IETF Secretariat and any 4329 assurances of licenses to be made available, or the result of an 4330 attempt made to obtain a general license or permission for the use of 4331 such proprietary rights by implementers or users of this 4332 specification can be obtained from the IETF on-line IPR repository at 4333 http://www.ietf.org/ipr. 4335 The IETF invites any interested party to bring to its attention any 4336 copyrights, patents or patent applications, or other proprietary 4337 rights that may cover technology that may be required to implement 4338 this standard. Please address the information to the IETF at 4339 ietf-ipr@ietf.org. 4341 Disclaimer of Validity 4343 This document and the information contained herein are provided on an 4344 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4345 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4346 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4347 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4348 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4349 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4351 Copyright Statement 4353 Copyright (C) The Internet Society (2004). This document is subject 4354 to the rights, licenses and restrictions contained in BCP 78, and 4355 except as set forth therein, the authors retain all their rights. 4357 Acknowledgment 4359 Funding for the RFC Editor function is currently provided by the 4360 Internet Society.