idnits 2.17.1 draft-ietf-l2tpext-l2tp-base-15.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 4326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4350. ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 1 longer page, the longest (page 1) being 68 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 26 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- 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 2033 has weird spacing: '... of tie break...' == Line 3247 has weird spacing: '...eptable conn...' == Line 3253 has weird spacing: '...CCN for wai...' == Line 3254 has weird spacing: '...breaker los...' == Line 3259 has weird spacing: '...ol-conn esta...' == (6 more instances...) -- 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 (December 2004) is 7034 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: 'RFC2890' is mentioned on line 4251, but not defined ** 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 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: 10 errors (**), 0 flaws (~~), 10 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Lau, Ed. 3 Internet Draft M. Townsley, Ed. 4 Category: Standards Track Cisco Systems 5 I. Goyret, Ed. 6 Lucent Technologies 7 December 2004 9 Layer Two Tunneling Protocol - Version 3 (L2TPv3) 10 draft-ietf-l2tpext-l2tp-base-15.txt 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). 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 nodes. Additional documents detail the specifics for each data 45 link type being emulated. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Changes from RFC 2661. . . . . . . . . . . . . . . . . . 4 51 1.2. Specification of Requirements. . . . . . . . . . . . . . 4 52 1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5 53 2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 54 3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 9 55 3.1. Control Message Types. . . . . . . . . . . . . . . . . . 10 56 3.2. L2TP Header Formats. . . . . . . . . . . . . . . . . . . 11 57 3.2.1. L2TP Control Message Header. . . . . . . . . . . 11 58 3.2.2. L2TP Data Message. . . . . . . . . . . . . . . . 12 59 3.3. Control Connection Management. . . . . . . . . . . . . . 13 60 3.3.1. Control Connection Establishment . . . . . . . . 14 61 3.3.2. Control Connection Teardown. . . . . . . . . . . 14 62 3.4. Session Management . . . . . . . . . . . . . . . . . . . 15 63 3.4.1. Session Establishment for an Incoming Call . . . 15 64 3.4.2. Session Establishment for an Outgoing Call . . . 15 65 3.4.3. Session Teardown . . . . . . . . . . . . . . . . 16 66 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16 67 4.1. L2TP Over Specific Packet-Switched Networks (PSNs) . . . 16 68 4.1.1. L2TPv3 over IP . . . . . . . . . . . . . . . . . 17 69 4.1.2. L2TP over UDP. . . . . . . . . . . . . . . . . . 18 70 4.1.3. L2TP and IPsec . . . . . . . . . . . . . . . . . 20 71 4.1.4. IP Fragmentation Issues. . . . . . . . . . . . . 21 72 4.2. Reliable Delivery of Control Messages. . . . . . . . . . 23 73 4.3. Control Message Authentication . . . . . . . . . . . . . 25 74 4.4. Keepalive (Hello). . . . . . . . . . . . . . . . . . . . 26 75 4.5. Forwarding Session Data Frames . . . . . . . . . . . . . 26 76 4.6. Default L2-Specific Sublayer . . . . . . . . . . . . . . 27 77 4.6.1. Sequencing Data Packets. . . . . . . . . . . . . 28 78 4.7. L2TPv2/v3 Interoperability and Migration . . . . . . . . 28 79 4.7.1. L2TPv3 over IP . . . . . . . . . . . . . . . . . 29 80 4.7.2. L2TPv3 over UDP. . . . . . . . . . . . . . . . . 29 81 4.7.3. Automatic L2TPv2 Fallback. . . . . . . . . . . . 29 82 5. Control Message Attribute Value Pairs. . . . . . . . . . . . . 30 83 5.1. AVP Format . . . . . . . . . . . . . . . . . . . . . . . 30 84 5.2. Mandatory AVPs and Setting the M Bit . . . . . . . . . . 32 85 5.3. Hiding of AVP Attribute Values . . . . . . . . . . . . . 33 86 5.4. AVP Summary. . . . . . . . . . . . . . . . . . . . . . . 36 87 5.4.1. General Control Message AVPs . . . . . . . . . . 36 88 5.4.2. Result and Error Codes . . . . . . . . . . . . . 40 89 5.4.3. Control Connection Management AVPs . . . . . . . 43 90 5.4.4. Session Management AVPs. . . . . . . . . . . . . 48 91 5.4.5. Circuit Status AVPs. . . . . . . . . . . . . . . 56 92 6. Control Connection Protocol Specification. . . . . . . . . . . 59 93 6.1. Start-Control-Connection-Request (SCCRQ) . . . . . . . . 59 94 6.2. Start-Control-Connection-Reply (SCCRP) . . . . . . . . . 60 95 6.3. Start-Control-Connection-Connected (SCCCN) . . . . . . . 60 96 6.4. Stop-Control-Connection-Notification (StopCCN) . . . . . 60 97 6.5. Hello (HELLO). . . . . . . . . . . . . . . . . . . . . . 61 98 6.6. Incoming-Call-Request (ICRQ) . . . . . . . . . . . . . . 61 99 6.7. Incoming-Call-Reply (ICRP) . . . . . . . . . . . . . . . 62 100 6.8. Incoming-Call-Connected (ICCN) . . . . . . . . . . . . . 63 101 6.9. Outgoing-Call-Request (OCRQ) . . . . . . . . . . . . . . 63 102 6.10. Outgoing-Call-Reply (OCRP) . . . . . . . . . . . . . . . 64 103 6.11. Outgoing-Call-Connected (OCCN) . . . . . . . . . . . . . 65 104 6.12. Call-Disconnect-Notify (CDN) . . . . . . . . . . . . . . 65 105 6.13. WAN-Error-Notify (WEN) . . . . . . . . . . . . . . . . . 66 106 6.14. Set-Link-Info (SLI). . . . . . . . . . . . . . . . . . . 66 107 6.15. Explicit-Acknowledgement (ACK) . . . . . . . . . . . . . 67 108 7. Control Connection State Machines. . . . . . . . . . . . . . . 67 109 7.1. Malformed AVPs and Control Messages. . . . . . . . . . . 67 110 7.2. Control Connection States. . . . . . . . . . . . . . . . 69 111 7.3. Incoming Calls . . . . . . . . . . . . . . . . . . . . . 71 112 7.3.1. ICRQ Sender States . . . . . . . . . . . . . . . 71 113 7.3.2. ICRQ Recipient States. . . . . . . . . . . . . . 73 114 7.4. Outgoing Calls . . . . . . . . . . . . . . . . . . . . . 74 115 7.4.1. OCRQ Sender States . . . . . . . . . . . . . . . 74 116 7.4.2. OCRQ Recipient (LAC) States. . . . . . . . . . . 76 117 7.5. Termination of a Control Connection. . . . . . . . . . . 77 118 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 77 119 8.1. Control Connection Endpoint and Message Security . . . . 78 120 8.2. Data Packet Spoofing . . . . . . . . . . . . . . . . . . 78 121 9. Internationalization Considerations. . . . . . . . . . . . . . 79 122 10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 80 123 10.1. Control Message Attribute Value Pairs (AVPs) . . . . . . 80 124 10.2. Message Type AVP Values. . . . . . . . . . . . . . . . . 81 125 10.3. Result Code AVP Values . . . . . . . . . . . . . . . . . 81 126 10.4. AVP Header Bits. . . . . . . . . . . . . . . . . . . . . 81 127 10.5. L2TP Control Message Header Bits . . . . . . . . . . . . 82 128 10.6. Pseudowire Types . . . . . . . . . . . . . . . . . . . . 82 129 10.7. Circuit Status Bits. . . . . . . . . . . . . . . . . . . 83 130 10.8. Default L2-Specific Sublayer bits. . . . . . . . . . . . 83 131 10.9. L2-Specific Sublayer Type. . . . . . . . . . . . . . . . 83 132 10.10 Data Sequencing Level. . . . . . . . . . . . . . . . . . 84 133 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84 134 11.1. Normative References . . . . . . . . . . . . . . . . . . 84 135 11.2. Informative References . . . . . . . . . . . . . . . . . 85 136 12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 86 137 Appendix A: Control Slow Start and Congestion Avoidance. . . . . . 88 138 Appendix B: Control Message Examples . . . . . . . . . . . . . . . 89 139 Appendix C: Processing Sequence Numbers. . . . . . . . . . . . . . 90 140 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 92 141 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 93 143 1. Introduction 145 The Layer Two Tunneling Protocol (L2TP) provides a dynamic mechanism 146 for tunneling Layer 2 (L2) "circuits" across a packet-oriented data 147 network (e.g., over IP). L2TP, as originally defined in RFC 2661, is 148 a standard method for tunneling Point-to-Point Protocol (PPP) 149 [RFC1661] sessions. L2TP has since been adopted for tunneling a 150 number of other L2 protocols. In order to provide greater 151 modularity, this document describes the base L2TP protocol, 152 independent of the L2 payload that is being tunneled. 154 The base L2TP protocol defined in this document consists of (1) the 155 control protocol for dynamic creation, maintenance, and teardown of 156 L2TP sessions, and (2) the L2TP data encapsulation to multiplex and 157 demultiplex L2 data streams between two L2TP nodes across an IP 158 network. Additional documents are expected to be published for each 159 L2 data link emulation type (a.k.a. pseudowire-type) supported by 160 L2TP (i.e., PPP, Ethernet, Frame Relay, etc.). These documents will 161 contain any pseudowire-type specific details that are outside the 162 scope of this base specification. 164 When the designation between L2TPv2 and L2TPv3 is necessary, L2TP as 165 defined in RFC 2661 will be referred to as "L2TPv2", corresponding to 166 the value in the Version field of an L2TP header. (Layer 2 167 Forwarding, L2F, [RFC2341] was defined as "version 1".) At times, 168 L2TP as defined in this document will be referred to as "L2TPv3". 169 Otherwise, the acronym "L2TP" will refer to L2TPv3 or L2TP in 170 general. 172 1.1. Changes from RFC 2661 174 Many of the protocol constructs described in this document are 175 carried over from RFC 2661. Changes include clarifications based on 176 years of interoperability and deployment experience as well as 177 modifications to either improve protocol operation or provide a 178 clearer separation from PPP. The intent of these modifications is to 179 achieve a healthy balance between code reuse, interoperability 180 experience, and a directed evolution of L2TP as it is applied to new 181 tasks. 183 Notable differences between L2TPv2 and L2TPv3 include the following: 185 Separation of all PPP-related AVPs, references, etc., including a 186 portion of the L2TP data header that was specific to the needs of 187 PPP. The PPP-specific constructs are described in a companion 188 document. 190 Transition from a 16-bit Session ID and Tunnel ID to a 32-bit 191 Session ID and Control Connection ID, respectively. 193 Extension of the Tunnel Authentication mechanism to cover the 194 entire control message rather than just a portion of certain 195 messages. 197 Details of these changes and a recommendation for transitioning to 198 L2TPv3 are discussed in Section 4.7. 200 1.2. Specification of Requirements 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in [RFC2119]. 206 1.3. Terminology 208 Attribute Value Pair (AVP) 210 The variable-length concatenation of a unique Attribute 211 (represented by an integer), a length field, and a Value 212 containing the actual value identified by the attribute. Zero or 213 more AVPs make up the body of control messages, which are used in 214 the establishment, maintenance, and teardown of control 215 connections. This basic construct is sometimes referred to as a 216 Type-Length-Value (TLV) in some specifications. (See also: 217 Control Connection, Control Message.) 219 Call (Circuit Up) 221 The action of transitioning a circuit on an L2TP Access 222 Concentrator (LAC) to an "up" or "active" state. A call may be 223 dynamically established through signaling properties (e.g., an 224 incoming or outgoing call through the Public Switched Telephone 225 Network (PSTN)) or statically configured (e.g., provisioning a 226 Virtual Circuit on an interface). A call is defined by its 227 properties (e.g., type of call, called number, etc.) and its data 228 traffic. (See also: Circuit, Session, Incoming Call, Outgoing 229 Call, Outgoing Call Request.) 231 Circuit 233 A general term identifying any one of a wide range of L2 234 connections. A circuit may be virtual in nature (e.g., an ATM 235 PVC, an IEEE 802 VLAN, or an L2TP session), or it may have direct 236 correlation to a physical layer (e.g., an RS-232 serial line). 237 Circuits may be statically configured with a relatively long-lived 238 uptime, or dynamically established with signaling to govern the 239 establishment, maintenance, and teardown of the circuit. For the 240 purposes of this document, a statically configured circuit is 241 considered to be essentially the same as a very simple, long- 242 lived, dynamic circuit. (See also: Call, Remote System.) 244 Client 246 (See Remote System.) 248 Control Connection 250 An L2TP control connection is a reliable control channel that is 251 used to establish, maintain, and release individual L2TP sessions 252 as well as the control connection itself. (See also: Control 253 Message, Data Channel.) 255 Control Message 257 An L2TP message used by the control connection. (See also: 258 Control Connection.) 260 Data Message 262 Message used by the data channel. (a.k.a. Data Packet, See also: 263 Data Channel.) 265 Data Channel 267 The channel for L2TP-encapsulated data traffic that passes between 268 two LCCEs over a Packet-Switched Network (i.e., IP). (See also: 269 Control Connection, Data Message.) 271 Incoming Call 273 The action of receiving a call (circuit up event) on an LAC. The 274 call may have been placed by a remote system (e.g., a phone call 275 over a PSTN), or it may have been triggered by a local event 276 (e.g., interesting traffic routed to a virtual interface). An 277 incoming call that needs to be tunneled (as determined by the LAC) 278 results in the generation of an L2TP ICRQ message. (See also: 279 Call, Outgoing Call, Outgoing Call Request.) 281 L2TP Access Concentrator (LAC) 283 If an L2TP Control Connection Endpoint (LCCE) is being used to 284 cross-connect an L2TP session directly to a data link, we refer to 285 it as an L2TP Access Concentrator (LAC). An LCCE may act as both 286 an L2TP Network Server (LNS) for some sessions and an LAC for 287 others, so these terms must only be used within the context of a 288 given set of sessions unless the LCCE is in fact single purpose 289 for a given topology. (See also: LCCE, LNS.) 291 L2TP Control Connection Endpoint (LCCE) 293 An L2TP node that exists at either end of an L2TP control 294 connection. May also be referred to as an LAC or LNS, depending 295 on whether tunneled frames are processed at the data link (LAC) or 296 network layer (LNS). (See also: LAC, LNS.) 298 L2TP Network Server (LNS) 300 If a given L2TP session is terminated at the L2TP node and the 301 encapsulated network layer (L3) packet processed on a virtual 302 interface, we refer to this L2TP node as an L2TP Network Server 303 (LNS). A given LCCE may act as both an LNS for some sessions and 304 an LAC for others, so these terms must only be used within the 305 context of a given set of sessions unless the LCCE is in fact 306 single purpose for a given topology. (See also: LCCE, LAC.) 308 Outgoing Call 310 The action of placing a call by an LAC, typically in response to 311 policy directed by the peer in an Outgoing Call Request. (See 312 also: Call, Incoming Call, Outgoing Call Request.) 314 Outgoing Call Request 316 A request sent to an LAC to place an outgoing call. The request 317 contains specific information not known a priori by the LAC (e.g., 318 a number to dial). (See also: Call, Incoming Call, Outgoing 319 Call.) 321 Packet-Switched Network (PSN) 323 A network that uses packet switching technology for data delivery. 324 For L2TPv3, this layer is principally IP. Other examples include 325 MPLS, Frame Relay, and ATM. 327 Peer 329 When used in context with L2TP, Peer refers to the far end of an 330 L2TP control connection (i.e., the remote LCCE). An LAC's peer 331 may be either an LNS or another LAC. Similarly, an LNS's peer may 332 be either an LAC or another LNS. (See also: LAC, LCCE, LNS.) 334 Pseudowire (PW) 336 An emulated circuit as it traverses a PSN. There is one 337 Pseudowire per L2TP Session. (See also: Packet-Switched Network, 338 Session.) 340 Pseudowire Type 342 The payload type being carried within an L2TP session. Examples 343 include PPP, Ethernet, and Frame Relay. (See also: Session.) 345 Remote System 347 An end system or router connected by a circuit to an LAC. 349 Session 351 An L2TP session is the entity that is created between two LCCEs in 352 order to exchange parameters for and maintain an emulated L2 353 connection. Multiple sessions may be associated with a single 354 Control Connection. 356 Zero-Length Body (ZLB) Message 358 A control message with only an L2TP header. ZLB messages are used 359 only to acknowledge messages on the L2TP reliable control 360 connection. (See also: Control Message.) 362 2. Topology 364 L2TP operates between two L2TP Control Connection Endpoints (LCCEs), 365 tunneling traffic across a packet network. There are three 366 predominant tunneling models in which L2TP operates: LAC-LNS (or vice 367 versa), LAC-LAC, and LNS-LNS. These models are diagrammed below. 368 (Dotted lines designate network connections. Solid lines designate 369 circuit connections.) 371 Figure 2.0: L2TP Reference Models 373 (a) LAC-LNS Reference Model: On one side, the LAC receives traffic 374 from an L2 circuit, which it forwards via L2TP across an IP or other 375 packet-based network. On the other side, an LNS logically terminates 376 the L2 circuit locally and routes network traffic to the home 377 network. The action of session establishment is driven by the LAC 378 (as an incoming call) or the LNS (as an outgoing call). 380 +-----+ L2 +-----+ +-----+ 381 | |------| LAC |.........[ IP ].........| LNS |...[home network] 382 +-----+ +-----+ +-----+ 383 remote 384 system 385 |<-- emulated service -->| 386 |<----------- L2 service ------------>| 388 (b) LAC-LAC Reference Model: In this model, both LCCEs are LACs. 389 Each LAC forwards circuit traffic from the remote system to the peer 390 LAC using L2TP, and vice versa. In its simplest form, an LAC acts as 391 a simple cross-connect between a circuit to a remote system and an 392 L2TP session. This model typically involves symmetric establishment; 393 that is, either side of the connection may initiate a session at any 394 time (or simultaneously, in which a tie breaking mechanism is 395 utilized). 397 +-----+ L2 +-----+ +-----+ L2 +-----+ 398 | |------| LAC |........[ IP ]........| LAC |------| | 399 +-----+ +-----+ +-----+ +-----+ 400 remote remote 401 system system 402 |<- emulated service ->| 403 |<----------------- L2 service ----------------->| 405 (c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs. A 406 user-level, traffic-generated, or signaled event typically drives 407 session establishment from one side of the tunnel. For example, a 408 tunnel generated from a PC by a user, or automatically by customer 409 premises equipment. 411 +-----+ +-----+ 412 [home network]...| LNS |........[ IP ]........| LNS |...[home network] 413 +-----+ +-----+ 414 |<- emulated service ->| 415 |<---- L2 service ---->| 417 Note: In L2TPv2, user-driven tunneling of this type is often referred 418 to as "voluntary tunneling" [RFC2809]. Further, an LNS acting as 419 part of a software package on a host is sometimes referred to as an 420 "LAC Client" [RFC2661]. 422 3. Protocol Overview 424 L2TP is comprised of two types of messages, control messages and data 425 messages (sometimes referred to as "control packets" and "data 426 packets", respectively). Control messages are used in the 427 establishment, maintenance, and clearing of control connections and 428 sessions. These messages utilize a reliable control channel within 429 L2TP to guarantee delivery (see Section 4.2 for details). Data 430 messages are used to encapsulate the L2 traffic being carried over 431 the L2TP session. Unlike control messages, data messages are not 432 retransmitted when packet loss occurs. 434 The L2TPv3 control message format defined in this document borrows 435 largely from L2TPv2. These control messages are used in conjunction 436 with the associated protocol state machines that govern the dynamic 437 setup, maintenance, and teardown for L2TP sessions. The data message 438 format for tunneling data packets may be utilized with or without the 439 L2TP control channel, either via manual configuration or via other 440 signaling methods to pre-configure or distribute L2TP session 441 information. Utilization of the L2TP data message format with other 442 signaling methods is outside the scope of this document. 444 Figure 3.0: L2TPv3 Structure 446 +-------------------+ +-----------------------+ 447 | Tunneled Frame | | L2TP Control Message | 448 +-------------------+ +-----------------------+ 449 | L2TP Data Header | | L2TP Control Header | 450 +-------------------+ +-----------------------+ 451 | L2TP Data Channel | | L2TP Control Channel | 452 | (unreliable) | | (reliable) | 453 +-------------------+----+-----------------------+ 454 | Packet-Switched Network (IP, FR, MPLS, etc.) | 455 +------------------------------------------------+ 457 Figure 3.0 depicts the relationship of control messages and data 458 messages over the L2TP control and data channels, respectively. Data 459 messages are passed over an unreliable data channel, encapsulated by 460 an L2TP header, and sent over a Packet-Switched Network (PSN) such as 461 IP, UDP, Frame Relay, ATM, MPLS, etc. Control messages are sent over 462 a reliable L2TP control channel, which operates over the same PSN. 464 The necessary setup for tunneling a session with L2TP consists of two 465 steps: (1) Establishing the control connection, and (2) establishing 466 a session as triggered by an incoming call or outgoing call. An L2TP 467 session MUST be established before L2TP can begin to forward session 468 frames. Multiple sessions may be bound to a single control 469 connection, and multiple control connections may exist between the 470 same two LCCEs. 472 3.1. Control Message Types 474 The Message Type AVP (see Section 5.4.1) defines the specific type of 475 control message being sent. 477 This document defines the following control message types (see 478 Sections 6.1 through 6.15 for details on the construction and use of 479 each message): 481 Control Connection Management 483 0 (reserved) 484 1 (SCCRQ) Start-Control-Connection-Request 485 2 (SCCRP) Start-Control-Connection-Reply 486 3 (SCCCN) Start-Control-Connection-Connected 487 4 (StopCCN) Stop-Control-Connection-Notification 488 5 (reserved) 489 6 (HELLO) Hello 490 20 (ACK) Explicit Acknowledgement 492 Call Management 494 7 (OCRQ) Outgoing-Call-Request 495 8 (OCRP) Outgoing-Call-Reply 496 9 (OCCN) Outgoing-Call-Connected 497 10 (ICRQ) Incoming-Call-Request 498 11 (ICRP) Incoming-Call-Reply 499 12 (ICCN) Incoming-Call-Connected 500 13 (reserved) 501 14 (CDN) Call-Disconnect-Notify 503 Error Reporting 505 15 (WEN) WAN-Error-Notify 507 Link Status Change Reporting 509 16 (SLI) Set-Link-Info 511 3.2. L2TP Header Formats 513 This section defines header formats for L2TP control messages and 514 L2TP data messages. All values are placed into their respective 515 fields and sent in network order (high-order octets first). 517 3.2.1. L2TP Control Message Header 519 The L2TP control message header provides information for the reliable 520 transport of messages that govern the establishment, maintenance, and 521 teardown of L2TP sessions. By default, control messages are sent 522 over the underlying media in-band with L2TP data messages. 524 The L2TP control message header is formatted as follows: 526 Figure 3.2.1: L2TP Control Message Header 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 |T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Control Connection ID | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Ns | Nr | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 The T bit MUST be set to 1, indicating that this is a control 539 message. 541 The L and S bits MUST be set to 1, indicating that the Length field 542 and sequence numbers are present. 544 The x bits are reserved for future extensions. All reserved bits 545 MUST be set to 0 on outgoing messages and ignored on incoming 546 messages. 548 The Ver field indicates the version of the L2TP control message 549 header described in this document. On sending, this field MUST be 550 set to 3 for all messages (unless operating in an environment that 551 includes L2TPv2 [RFC2661] and/or L2F [RFC2341] as well, see Section 552 4.1 for details). 554 The Length field indicates the total length of the message in octets, 555 always calculated from the start of the control message header itself 556 (beginning with the T bit). 558 The Control Connection ID field contains the identifier for the 559 control connection. L2TP control connections are named by 560 identifiers that have local significance only. That is, the same 561 control connection will be given unique Control Connection IDs by 562 each LCCE from within each endpoint's own Control Connection ID 563 number space. As such, the Control Connection ID in each message is 564 that of the intended recipient, not the sender. Non-zero Control 565 Connection IDs are selected and exchanged as Assigned Control 566 Connection ID AVPs during the creation of a control connection. 568 Ns indicates the sequence number for this control message, beginning 569 at zero and incrementing by one (modulo 2**16) for each message sent. 570 See Section 4.2 for more information on using this field. 572 Nr indicates the sequence number expected in the next control message 573 to be received. Thus, Nr is set to the Ns of the last in-order 574 message received plus one (modulo 2**16). See Section 4.2 for more 575 information on using this field. 577 3.2.2. L2TP Data Message 579 In general, an L2TP data message consists of a (1) Session Header, 580 (2) an optional L2-Specific Sublayer, and (3) the Tunnel Payload, as 581 depicted below. 583 Figure 3.2.2: L2TP Data Message Header 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | L2TP Session Header | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | L2-Specific Sublayer | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Tunnel Payload ... 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 The L2TP Session Header is specific to the encapsulating PSN over 594 which the L2TP traffic is delivered. The Session Header MUST provide 595 (1) a method of distinguishing traffic among multiple L2TP data 596 sessions and (2) a method of distinguishing data messages from 597 control messages. 599 Each type of encapsulating PSN MUST define its own session header, 600 clearly identifying the format of the header and parameters necessary 601 to setup the session. Section 4.1 defines two session headers, one 602 for transport over UDP and one for transport over IP. 604 The L2-Specific Sublayer is an intermediary layer between the L2TP 605 session header and the start of the tunneled frame. It contains 606 control fields that are used to facilitate the tunneling of each 607 frame (e.g., sequence numbers or flags). The Default L2-Specific 608 Sublayer for L2TPv3 is defined in Section 4.6. 610 The Data Message Header is followed by the Tunnel Payload, including 611 any necessary L2 framing as defined in the payload-specific companion 612 documents. 614 3.3. Control Connection Management 616 The L2TP control connection handles dynamic establishment, teardown, 617 and maintenance of the L2TP sessions and of the control connection 618 itself. The reliable delivery of control messages is described in 619 Section 4.2. 621 This section describes typical control connection establishment and 622 teardown exchanges. It is important to note that, in the diagrams 623 that follow, the reliable control message delivery mechanism exists 624 independently of the L2TP state machine. For instance, Explicit 625 Acknowledgement (ACK) messages may be sent after any of the control 626 messages indicated in the exchanges below if an acknowledgment is not 627 piggybacked on a later control message. 629 LCCEs are identified during control connection establishment either 630 by the Host Name AVP, the Router ID AVP, or a combination of the two 631 (see Section 5.4.3). The identity of a peer LCCE is central to 632 selecting proper configuration parameters (i.e., Hello interval, 633 window size, etc.) for a control connection, as well as for 634 determining how to set up associated sessions within the control 635 connection, password lookup for control connection authentication, 636 control connection level tie breaking, etc. 638 3.3.1. Control Connection Establishment 640 Establishment of the control connection involves an exchange of AVPs 641 that identifies the peer and its capabilities. 643 A three-message exchange is used to establish the control connection. 644 The following is a typical message exchange: 646 LCCE A LCCE B 647 ------ ------ 648 SCCRQ -> 649 <- SCCRP 650 SCCCN -> 652 3.3.2. Control Connection Teardown 654 Control connection teardown may be initiated by either LCCE and is 655 accomplished by sending a single StopCCN control message. As part of 656 the reliable control message delivery mechanism, the recipient of a 657 StopCCN MUST send an ACK message to acknowledge receipt of the 658 message and maintain enough control connection state to properly 659 accept StopCCN retransmissions over at least a full retransmission 660 cycle (in case the ACK message is lost). The recommended time for a 661 full retransmission cycle is at least 31 seconds (see Section 4.2). 662 The following is an example of a typical control message exchange: 664 LCCE A LCCE B 665 ------ ------ 666 StopCCN -> 667 (Clean up) 669 (Wait) 670 (Clean up) 672 An implementation may shut down an entire control connection and all 673 sessions associated with the control connection by sending the 674 StopCCN. Thus, it is not necessary to clear each session 675 individually when tearing down the whole control connection. 677 3.4. Session Management 679 After successful control connection establishment, individual 680 sessions may be created. Each session corresponds to a single data 681 stream between the two LCCEs. This section describes the typical 682 call establishment and teardown exchanges. 684 3.4.1. Session Establishment for an Incoming Call 686 A three-message exchange is used to establish the session. The 687 following is a typical sequence of events: 689 LCCE A LCCE B 690 ------ ------ 691 (Call 692 Detected) 694 ICRQ -> 695 <- ICRP 696 (Call 697 Accepted) 699 ICCN -> 701 3.4.2. Session Establishment for an Outgoing Call 703 A three-message exchange is used to set up the session. The 704 following is a typical sequence of events: 706 LCCE A LCCE B 707 ------ ------ 708 <- OCRQ 709 OCRP -> 711 (Perform 712 Call 713 Operation) 715 OCCN -> 717 (Call Operation 718 Completed 719 Successfully) 721 3.4.3. Session Teardown 723 Session teardown may be initiated by either the LAC or LNS and is 724 accomplished by sending a CDN control message. After the last 725 session is cleared, the control connection MAY be torn down as well 726 (and typically is). The following is an example of a typical control 727 message exchange: 729 LCCE A LCCE B 730 ------ ------ 731 CDN -> 732 (Clean up) 734 (Clean up) 736 4. Protocol Operation 738 4.1. L2TP Over Specific Packet-Switched Networks (PSNs) 740 L2TP may operate over a variety of PSNs. There are two modes 741 described for operation over IP, L2TP directly over IP (see Section 742 4.1.1) and L2TP over UDP (see Section 4.1.2). L2TPv3 implementations 743 MUST support L2TP over IP and SHOULD support L2TP over UDP for better 744 NAT and firewall traversal, and for easier migration from L2TPv2. 746 L2TP over other PSNs may be defined, but the specifics are outside 747 the scope of this document. Examples of L2TPv2 over other PSNs 748 include [RFC3070] and [RFC3355]. 750 The following field definitions are defined for use in all L2TP 751 Session Header encapsulations. 753 Session ID 755 A 32-bit field containing a non-zero identifier for a session. 756 L2TP sessions are named by identifiers that have local 757 significance only. That is, the same logical session will be 758 given different Session IDs by each end of the control connection 759 for the life of the session. When the L2TP control connection is 760 used for session establishment, Session IDs are selected and 761 exchanged as Local Session ID AVPs during the creation of a 762 session. The Session ID alone provides the necessary context for 763 all further packet processing, including the presence, size, and 764 value of the Cookie, the type of L2-Specific Sublayer, and the 765 type of payload being tunneled. 767 Cookie 769 The optional Cookie field contains a variable-length value 770 (maximum 64 bits) used to check the association of a received data 771 message with the session identified by the Session ID. The Cookie 772 MUST be set to the configured or signaled random value for this 773 session. The Cookie provides an additional level of guarantee 774 that a data message has been directed to the proper session by the 775 Session ID. A well-chosen Cookie may prevent inadvertent 776 misdirection of stray packets with recently reused Session IDs, 777 Session IDs subject to packet corruption, etc. The Cookie may 778 also provide protection against some specific malicious packet 779 insertion attacks, as described in Section 8.2. 781 When the L2TP control connection is used for session 782 establishment, random Cookie values are selected and exchanged as 783 Assigned Cookie AVPs during session creation. 785 4.1.1. L2TPv3 over IP 787 L2TPv3 over IP (both versions) utilizes the IANA-assigned IP protocol 788 ID 115. 790 4.1.1.1. L2TPv3 Session Header Over IP 792 Unlike L2TP over UDP, the L2TPv3 session header over IP is free of 793 any restrictions imposed by coexistence with L2TPv2 and L2F. As 794 such, the header format has been designed to optimize packet 795 processing. The following session header format is utilized when 796 operating L2TPv3 over IP: 798 Figure 4.1.1.1: L2TPv3 Session Header Over IP 800 0 1 2 3 801 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 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Session ID | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Cookie (optional, maximum 64 bits)... 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 The Session ID and Cookie fields are as defined in Section 4.1. The 811 Session ID of zero is reserved for use by L2TP control messages (see 812 Section 4.1.1.2). 814 4.1.1.2. L2TP Control and Data Traffic over IP 816 Unlike L2TP over UDP, which uses the T bit to distinguish between 817 L2TP control and data packets, L2TP over IP uses the reserved Session 818 ID of zero (0) when sending control messages. It is presumed that 819 checking for the zero Session ID is more efficient -- both in header 820 size for data packets and in processing speed for distinguishing 821 between control and data messages -- than checking a single bit. 823 The entire control message header over IP, including the zero session 824 ID, appears as follows: 826 Figure 4.1.1.2: L2TPv3 Control Message Header Over IP 828 0 1 2 3 829 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 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | (32 bits of zeros) | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 |T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Control Connection ID | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Ns | Nr | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 Named fields are as defined in Section 3.2.1. Note that the Length 841 field is still calculated from the beginning of the control message 842 header, beginning with the T bit. It does NOT include the "(32 bits 843 of zeros)" depicted above. 845 When operating directly over IP, L2TP packets lose the ability to 846 take advantage of the UDP checksum as a simple packet integrity 847 check, which is of particular concern for L2TP control messages. 848 Control Message Authentication (see Section 4.3), even with an empty 849 password field, provides for a sufficient packet integrity check and 850 SHOULD always be enabled. 852 4.1.2. L2TP over UDP 854 L2TPv3 over UDP must consider other L2 tunneling protocols that may 855 be operating in the same environment, including L2TPv2 [RFC2661] and 856 L2F [RFC2341]. 858 While there are efficiencies gained by running L2TP directly over IP, 859 there are possible side effects as well. For instance, L2TP over IP 860 is not as NAT-friendly as L2TP over UDP. 862 4.1.2.1. L2TP Session Header Over UDP 864 The following session header format is utilized when operating L2TPv3 865 over UDP: 867 Figure 4.1.2.1: L2TPv3 Session Header over UDP 869 0 1 2 3 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 |T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Session ID | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Cookie (optional, maximum 64 bits)... 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 The T bit MUST be set to 0, indicating that this is a data message. 883 The x bits and Reserved field are reserved for future extensions. 884 All reserved values MUST be set to 0 on outgoing messages and ignored 885 on incoming messages. 887 The Ver field MUST be set to 3, indicating an L2TPv3 message. 889 Note that the initial bits 1, 4, 6, and 7 have meaning in L2TPv2 890 [RFC2661], and are deprecated and marked as reserved in L2TPv3. 891 Thus, for UDP mode on a system that supports both versions of L2TP, 892 it is important that the Ver field be inspected first to determine 893 the Version of the header before acting upon any of these bits. 895 The Session ID and Cookie fields are as defined in Section 4.1. 897 4.1.2.2. UDP Port Selection 899 The method for UDP Port Selection defined in this section is 900 identical to that defined for L2TPv2 [RFC2661]. 902 When negotiating a control connection over UDP, control messages MUST 903 be sent as UDP datagrams using the registered UDP port 1701 904 [RFC1700]. The initiator of an L2TP control connection picks an 905 available source UDP port (which may or may not be 1701) and sends to 906 the desired destination address at port 1701. The recipient picks a 907 free port on its own system (which may or may not be 1701) and sends 908 its reply to the initiator's UDP port and address, setting its own 909 source port to the free port it found. 911 Any subsequent traffic associated with this control connection 912 (either control traffic or data traffic from a session established 913 through this control connection) must use these same UDP ports. 915 It has been suggested that having the recipient choose an arbitrary 916 source port (as opposed to using the destination port in the packet 917 initiating the control connection, i.e., 1701) may make it more 918 difficult for L2TP to traverse some NAT devices. Implementations 919 should consider the potential implication of this capability before 920 choosing an arbitrary source port. A NAT device that can pass TFTP 921 traffic with variant UDP ports should be able to pass L2TP UDP 922 traffic since both protocols employ similar policies with regard to 923 UDP port selection. 925 4.1.2.3. UDP Checksum 927 The tunneled frames that L2TP carry often have their own checksums or 928 integrity checks, rendering the UDP checksum redundant for much of 929 the L2TP data message contents. Thus, UDP checksums MAY be disabled 930 in order to reduce the associated packet processing burden at the 931 L2TP endpoints. 933 The L2TP header itself does not have its own checksum or integrity 934 check. However, use of the L2TP Session ID and Cookie pair guards 935 against accepting an L2TP data message if corruption of the Session 936 ID or associated Cookie has occurred. When the L2-Specific Sublayer 937 is present in the L2TP header, there is no built-in integrity check 938 for the information contained therein if UDP checksums or some other 939 integrity check is not employed. IPsec (see Section 4.1.3) may be 940 used for strong integrity protection of the entire contents of L2TP 941 data messages. 943 UDP checksums MUST be enabled for L2TP control messages. 945 4.1.3. L2TP and IPsec 947 The L2TP data channel does not provide cryptographic security of any 948 kind. If the L2TP data channel operates over a public or untrusted 949 IP network where privacy of the L2TP data is of concern or 950 sophisticated attacks against L2TP are expected to occur, IPsec 951 [RFC2401] MUST be made available to secure the L2TP traffic. 953 Either L2TP over UDP or L2TP over IP may be secured with IPsec. 954 [RFC3193] defines the recommended method for securing L2TPv2. L2TPv3 955 possesses identical characteristics to IPsec as L2TPv2 when running 956 over UDP and implementations MUST follow the same recommendation. 957 When operating over IP directly, [RFC3193] still applies, though 958 references to UDP source and destination ports (in particular, those 959 in Section 4, "IPsec Filtering details when protecting L2TP") may be 960 ignored. Instead, the selectors used to identify L2TPv3 traffic are 961 simply the source and destination IP addresses for the tunnel 962 endpoints together with the L2TPv3 IP protocol type, 115. 964 In addition to IP transport security, IPsec defines a mode of 965 operation that allows tunneling of IP packets. The packet-level 966 encryption and authentication provided by IPsec tunnel mode and that 967 provided by L2TP secured with IPsec provide an equivalent level of 968 security for these requirements. 970 IPsec also defines access control features that are required of a 971 compliant IPsec implementation. These features allow filtering of 972 packets based upon network and transport layer characteristics such 973 as IP address, ports, etc. In the L2TP tunneling model, analogous 974 filtering may be performed at the network layer above L2TP. These 975 network layer access control features may be handled at an LCCE via 976 vendor-specific authorization features, or at the network layer 977 itself by using IPsec transport mode end-to-end between the 978 communicating hosts. The requirements for access control mechanisms 979 are not a part of the L2TP specification, and as such, are outside 980 the scope of this document. 982 Protecting the L2TP packet stream with IPsec does, in turn, also 983 protect the data within the tunneled session packets while 984 transported from one LCCE to the other. Such protection must not be 985 considered a substitution for end-to-end security between 986 communicating hosts or applications. 988 4.1.4. IP Fragmentation Issues 990 Fragmentation and reassembly in network equipment generally require 991 significantly greater resources than sending or receiving a packet as 992 a single unit. As such, fragmentation and reassembly should be 993 avoided whenever possible. Ideal solutions for avoiding 994 fragmentation include proper configuration and management of MTU 995 sizes among the Remote System, the LCCE, and the IP network, as well 996 as adaptive measures that operate with the originating host (e.g., 997 [RFC1191], [RFC1981]) to reduce the packet sizes at the source. 999 An LCCE MAY fragment a packet before encapsulating it in L2TP. For 1000 example, if an IPv4 packet arrives at an LCCE from a Remote System 1001 that, after encapsulation with its associated framing, L2TP, and IP, 1002 does not fit in the available path MTU towards its LCCE peer, the 1003 local LCCE may perform IPv4 fragmentation on the packet before tunnel 1004 encapsulation. This creates two (or more) L2TP packets, each 1005 carrying an IPv4 fragment with its associated framing. This 1006 ultimately has the effect of placing the burden of fragmentation on 1007 the LCCE, while reassembly occurs on the IPv4 destination host. 1009 If an IPv6 packet arrives at an LCCE from a Remote System that, after 1010 encapsulation with associated framing, L2TP and IP, does not fit in 1011 the available path MTU towards its L2TP peer, the Generic Packet 1012 Tunneling specification [RFC2473], Section 7.1 SHOULD be followed. In 1013 this case, the LCCE should either send an ICMP Packet Too Big message 1014 to the data source, or fragment the resultant L2TP/IP packet (for 1015 reassembly by the L2TP peer). 1017 If the amount of traffic requiring fragmentation and reassembly is 1018 rather light, or there are sufficiently optimized mechanisms at the 1019 tunnel endpoints, fragmentation of the L2TP/IP packet may be 1020 sufficient for accommodating mismatched MTUs that cannot be managed 1021 by more efficient means. This method effectively emulates a larger 1022 MTU between tunnel endpoints and should work for any type of L2- 1023 encapsulated packet. Note that IPv6 does not support "in-flight" 1024 fragmentation of data packets. Thus, unlike IPv4, the MTU of the 1025 path towards an L2TP peer must be known in advance (or the last 1026 resort IPv6 minimum MTU of 1280 bytes utilized) so that IPv6 1027 fragmentation may occur at the LCCE. 1029 In summary, attempting to control the source MTU by communicating 1030 with the originating host, forcing that an MTU be sufficiently large 1031 on the path between LCCE peers to tunnel a frame from any other 1032 interface without fragmentation, fragmenting IP packets before 1033 encapsulation with L2TP/IP, or fragmenting the resultant L2TP/IP 1034 packet between the tunnel endpoints, are all valid methods for 1035 managing MTU mismatches. Some are clearly better than others 1036 depending on the given deployment. For example, a passive monitoring 1037 application using L2TP would certainly not wish to have ICMP messages 1038 sent to a traffic source. Further, if the links connecting a set of 1039 LCCEs have a very large MTU (e.g., SDH/SONET) and it is known that 1040 the MTU of all links being tunneled by L2TP have smaller MTUs (e.g., 1041 1500 bytes), then any IP fragmentation and reassembly enabled on the 1042 participating LCCEs would never be utilized. An implementation MUST 1043 implement at least one of the methods described in this section for 1044 managing mismatched MTUs, based on careful consideration of how the 1045 final product will be deployed. 1047 L2TP-specific fragmentation and reassembly methods, which may or may 1048 not depend on the characteristics of the type of link being tunneled 1049 (e.g., judicious packing of ATM cells), may be defined as well, but 1050 these methods are outside the scope of this document. 1052 4.2. Reliable Delivery of Control Messages 1054 L2TP provides a lower level reliable delivery service for all control 1055 messages. The Nr and Ns fields of the control message header (see 1056 Section 3.2.1) belong to this delivery mechanism. The upper level 1057 functions of L2TP are not concerned with retransmission or ordering 1058 of control messages. The reliable control messaging mechanism is a 1059 sliding window mechanism that provides control message retransmission 1060 and congestion control. Each peer maintains separate sequence number 1061 state for each control connection. 1063 The message sequence number, Ns, begins at 0. Each subsequent 1064 message is sent with the next increment of the sequence number. The 1065 sequence number is thus a free-running counter represented modulo 1066 65536. The sequence number in the header of a received message is 1067 considered less than or equal to the last received number if its 1068 value lies in the range of the last received number and the preceding 1069 32767 values, inclusive. For example, if the last received sequence 1070 number was 15, then messages with sequence numbers 0 through 15, as 1071 well as 32784 through 65535, would be considered less than or equal. 1072 Such a message would be considered a duplicate of a message already 1073 received and ignored from processing. However, in order to ensure 1074 that all messages are acknowledged properly (particularly in the case 1075 of a lost ACK message), receipt of duplicate messages MUST be 1076 acknowledged by the reliable delivery mechanism. This acknowledgment 1077 may either piggybacked on a message in queue or sent explicitly via 1078 an ACK message. 1080 All control messages take up one slot in the control message sequence 1081 number space, except the ACK message. Thus, Ns is not incremented 1082 after an ACK message is sent. 1084 The last received message number, Nr, is used to acknowledge messages 1085 received by an L2TP peer. It contains the sequence number of the 1086 message the peer expects to receive next (e.g., the last Ns of a 1087 non-ACK message received plus 1, modulo 65536). While the Nr in a 1088 received ACK message is used to flush messages from the local 1089 retransmit queue (see below), the Nr of the next message sent is not 1090 updated by the Ns of the ACK message. Nr SHOULD be sanity-checked 1091 before flushing the retransmit queue. For instance, if the Nr 1092 received in a control message is greater than the last Ns sent plus 1 1093 modulo 65536, the control message is clearly invalid. 1095 The reliable delivery mechanism at a receiving peer is responsible 1096 for making sure that control messages are delivered in order and 1097 without duplication to the upper level. Messages arriving out-of- 1098 order may be queued for in-order delivery when the missing messages 1099 are received. Alternatively, they may be discarded, thus requiring a 1100 retransmission by the peer. When dropping out-of-order control 1101 packets, Nr MAY be updated before the packet is discarded. 1103 Each control connection maintains a queue of control messages to be 1104 transmitted to its peer. The message at the front of the queue is 1105 sent with a given Ns value and is held until a control message 1106 arrives from the peer in which the Nr field indicates receipt of this 1107 message. After a period of time (a recommended default is 1 second 1108 but SHOULD be configurable) passes without acknowledgment, the 1109 message is retransmitted. The retransmitted message contains the 1110 same Ns value, but the Nr value MUST be updated with the sequence 1111 number of the next expected message. 1113 Each subsequent retransmission of a message MUST employ an 1114 exponential backoff interval. Thus, if the first retransmission 1115 occurred after 1 second, the next retransmission should occur after 2 1116 seconds has elapsed, then 4 seconds, etc. An implementation MAY 1117 place a cap upon the maximum interval between retransmissions. This 1118 cap SHOULD be no less than 8 seconds per retransmission. If no peer 1119 response is detected after several retransmissions (a recommended 1120 default is 10, but MUST be configurable), the control connection and 1121 all associated sessions MUST be cleared. As it is the first message 1122 to establish a control connection, the SCCRQ MAY employ a different 1123 retransmission maximum than other control messages in order to help 1124 facilitate failover to alternate LCCEs in a timely fashion. 1126 When a control connection is being shut down for reasons other than 1127 loss of connectivity, the state and reliable delivery mechanisms MUST 1128 be maintained and operated for the full retransmission interval after 1129 the final message StopCCN message has been sent (e.g., 1 + 2 + 4 + 8 1130 + 8... seconds), or until the StopCCN message itself has been 1131 acknowledged. 1133 A sliding window mechanism is used for control message transmission 1134 and retransmission. Consider two peers, A and B. Suppose A 1135 specifies a Receive Window Size AVP with a value of N in the SCCRQ or 1136 SCCRP message. B is now allowed to have a maximum of N outstanding 1137 (i.e., unacknowledged) control messages. Once N messages have been 1138 sent, B must wait for an acknowledgment from A that advances the 1139 window before sending new control messages. An implementation may 1140 advertise a non-zero receive window as small or as large as it 1141 wishes, depending on its own ability to process incoming messages 1142 before sending an acknowledgement. Each peer MUST limit the number 1143 of unacknowledged messages it will send before receiving an 1144 acknowledgement by this Receive Window Size. The actual internal 1145 unacknowledged message send-queue depth may be further limited by 1146 local resource allocation or by dynamic slow-start and congestion- 1147 avoidance mechanisms. 1149 When retransmitting control messages, a slow start and congestion 1150 avoidance window adjustment procedure SHOULD be utilized. A 1151 recommended procedure is described in Appendix A. A peer MAY drop 1152 messages, but MUST NOT actively delay acknowledgment of messages as a 1153 technique for flow control of control messages. Appendix B contains 1154 examples of control message transmission, acknowledgment, and 1155 retransmission. 1157 4.3. Control Message Authentication 1159 L2TP incorporates an optional authentication and integrity check for 1160 all control messages. This mechanism consists of a computed one-way 1161 hash over the header and body of the L2TP control message, a pre- 1162 configured shared secret, and a local and remote nonce (random value) 1163 exchanged via the Control Message Authentication Nonce AVP. This 1164 per-message authentication and integrity check is designed to perform 1165 a mutual authentication between L2TP nodes, perform integrity 1166 checking of all control messages, and guard against control message 1167 spoofing and replay attacks that would otherwise be trivial to mount. 1169 At least one shared secret (password) MUST exist between 1170 communicating L2TP nodes to enable Control Message Authentication. 1171 See Section 5.4.3 for details on calculation of the Message Digest 1172 and construction of the Control Message Authentication Nonce and 1173 Message Digest AVPs. 1175 L2TPv3 Control Message Authentication is similar to L2TPv2 [RFC2661] 1176 Tunnel Authentication in its use of a shared secret and one-way hash 1177 calculation. The principal difference is that, instead of computing 1178 the hash over selected contents of a received control message (e.g., 1179 the Challenge AVP and Message Type) as in L2TPv2, the entire message 1180 is used in the hash in L2TPv3. In addition, instead of including the 1181 hash digest in just the SCCRP and SCCCN messages, it is now included 1182 in all L2TP messages. 1184 The Control Message Authentication mechanism is optional, and may be 1185 disabled if both peers agree. For example, if IPsec is already being 1186 used for security and integrity checking between the LCCEs, the 1187 function of the L2TP mechanism becomes redundant and may be disabled. 1189 Presence of the Control Message Authentication Nonce AVP in an SCCRQ 1190 or SCCRP message serves as indication to a peer that Control Message 1191 Authentication is enabled. If an SCCRQ or SCCRP contains a Control 1192 Message Authentication Nonce AVP, the receiver of the message MUST 1193 respond with a Message Digest AVP in all subsequent messages sent. 1194 Control Message Authentication is always bidirectional; either both 1195 sides participate in authentication, or neither does. 1197 If Control Message Authentication is disabled, the Message Digest AVP 1198 still MAY be sent as an integrity check of the message. The 1199 integrity check is calculated as in Section 5.4.3, with an empty 1200 zero-length shared secret, local nonce, and remote nonce. If an 1201 invalid Message Digest is received, it should be assumed that the 1202 message has been corrupted in transit and the message dropped 1203 accordingly. 1205 Implementations MAY rate-limit control messages, particularly SCCRQ 1206 messages, upon receipt for performance reasons or for protection 1207 against denial of service attacks. 1209 4.4. Keepalive (Hello) 1211 L2TP employs a keepalive mechanism to detect loss of connectivity 1212 between a pair of LCCEs. This is accomplished by injecting Hello 1213 control messages (see Section 6.5) after a period of time has elapsed 1214 since the last data message or control message was received on an 1215 L2TP session or control connection, respectively. As with any other 1216 control message, if the Hello message is not reliably delivered, the 1217 sending LCCE declares that the control connection is down and resets 1218 its state for the control connection. This behavior ensures that a 1219 connectivity failure between the LCCEs is detected independently by 1220 each end of a control connection. 1222 Since the control channel is operated in-band with data traffic over 1223 the PSN, this single mechanism can be used to infer basic data 1224 connectivity between a pair of LCCEs for all sessions associated with 1225 the control connection. 1227 Periodic keepalive for the control connection MUST be implemented by 1228 sending a Hello if a period of time (a recommended default is 60 1229 seconds, but MUST be configurable) has passed without receiving any 1230 message (data or control) from the peer. An LCCE sending Hello 1231 messages across multiple control connections between the same LCCE 1232 endpoints MUST employ a jittered timer mechanism to prevent grouping 1233 of Hello messages. 1235 4.5. Forwarding Session Data Frames 1237 Once session establishment is complete, circuit frames are received 1238 at an LCCE, encapsulated in L2TP (with appropriate attention to 1239 framing, as described in documents for the particular pseudowire 1240 type), and forwarded over the appropriate session. For every 1241 outgoing data message, the sender places the identifier specified in 1242 the Local Session ID AVP (received from peer during session 1243 establishment) in the Session ID field of the L2TP data header. In 1244 this manner, session frames are multiplexed and demultiplexed between 1245 a given pair of LCCEs. Multiple control connections may exist 1246 between a given pair of LCCEs, and multiple sessions may be 1247 associated with a given control connection. 1249 The peer LCCE receiving the L2TP data packet identifies the session 1250 with which the packet is associated by the Session ID in the data 1251 packet's header. The LCCE then checks the Cookie field in the data 1252 packet against the Cookie value received in the Assigned Cookie AVP 1253 during session establishment. It is important for implementers to 1254 note that the Cookie field check occurs after looking up the session 1255 context by the Session ID, and as such, consists merely of a value 1256 match of the Cookie field and that stored in the retrieved context. 1257 There is no need to perform a lookup across the Session ID and Cookie 1258 as a single value. Any received data packets that contain invalid 1259 Session IDs or associated Cookie values MUST be dropped. Finally, 1260 the LCCE either forwards the network packet within the tunneled frame 1261 (e.g., as an LNS) or switches the frame to a circuit (e.g., as an 1262 LAC). 1264 4.6. Default L2-Specific Sublayer 1266 This document defines a Default L2-Specific Sublayer format (see 1267 Section 3.2.2) that a pseudowire may use for features such as 1268 sequencing support, L2 interworking, OAM, or other per-data-packet 1269 operations. The Default L2-Specific Sublayer SHOULD be used by a 1270 given PW type to support these features if it is adequate, and its 1271 presence is requested by a peer during session negotiation. 1272 Alternative sublayers MAY be defined (e.g., an encapsulation with a 1273 larger Sequence Number field or timing information) and identified 1274 for use via the L2-Specific Sublayer Type AVP. 1276 Figure 4.6: Default L2-Specific Sublayer Format 1278 0 1 2 3 1279 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 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 |x|S|x|x|x|x|x|x| Sequence Number | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 The S (Sequence) bit is set to 1 when the Sequence Number contains a 1285 valid number for this sequenced frame. If the S bit is set to zero, 1286 the Sequence Number contents are undefined and MUST be ignored by the 1287 receiver. 1289 The Sequence Number field contains a free-running counter of 2^24 1290 sequence numbers. If the number in this field is valid, the S bit 1291 MUST be set to 1. The Sequence Number begins at zero, which is a 1292 valid sequence number. (In this way, implementations inserting 1293 sequence numbers do not have to "skip" zero when incrementing.) The 1294 sequence number in the header of a received message is considered 1295 less than or equal to the last received number if its value lies in 1296 the range of the last received number and the preceding (2^23-1) 1297 values, inclusive. 1299 4.6.1. Sequencing Data Packets 1301 The Sequence Number field may be used to detect lost, duplicate, or 1302 out-of-order packets within a given session. 1304 When L2 frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP 1305 data channel, this part of the link has the characteristic of being 1306 able to reorder, duplicate, or silently drop packets. Reordering may 1307 break some non-IP protocols or L2 control traffic being carried by 1308 the link. Silent dropping or duplication of packets may break 1309 protocols that assume per-packet indications of error, such as TCP 1310 header compression. While a common mechanism for packet sequence 1311 detection is provided, the sequence dependency characteristics of 1312 individual protocols are outside the scope of this document. 1314 If any protocol being transported by over L2TP data channels cannot 1315 tolerate misordering of data packets, packet duplication, or silent 1316 packet loss, sequencing may be enabled on some or all packets by 1317 using the S bit and Sequence Number field defined in the Default L2- 1318 Specific Sublayer (see Section 4.6). For a given L2TP session, each 1319 LCCE is responsible for communicating to its peer the level of 1320 sequencing support that it requires of data packets that it receives. 1321 Mechanisms to advertise this information during session negotiation 1322 are provided (see Data Sequencing AVP in Section 5.4.4). 1324 When determining whether a packet is in or out of sequence, an 1325 implementation SHOULD utilize a method that is resilient to temporary 1326 dropouts in connectivity coupled with high per-session packet rates. 1327 The recommended method is outlined in Appendix C. 1329 4.7. L2TPv2/v3 Interoperability and Migration 1331 L2TPv2 and L2TPv3 environments should be able to coexist while a 1332 migration to L2TPv3 is made. Migration issues are discussed for each 1333 media type in this section. Most issues apply only to 1334 implementations that require both L2TPv2 and L2TPv3 operation. 1336 However, even L2TPv3-only implementations must at least be mindful of 1337 these issues in order to interoperate with implementations that 1338 support both versions. 1340 4.7.1. L2TPv3 over IP 1342 L2TPv3 implementations running strictly over IP with no desire to 1343 interoperate with L2TPv2 implementations may safely disregard most 1344 migration issues from L2TPv2. All control messages and data messages 1345 are sent as described in this document, without normative reference 1346 to RFC 2661. 1348 If one wishes to tunnel PPP over L2TPv3, and fallback to L2TPv2 only 1349 if it is not available, then L2TPv3 over UDP with automatic fallback 1350 (see Section 4.7.3) MUST be used. There is no deterministic method 1351 for automatic fallback from L2TPv3 over IP to either L2TPv2 or L2TPv3 1352 over UDP. One could infer whether L2TPv3 over IP is supported by 1353 sending an SCCRQ and waiting for a response, but this could be 1354 problematic during periods of packet loss between L2TP nodes. 1356 4.7.2. L2TPv3 over UDP 1358 The format of the L2TPv3 over UDP header is defined in Section 1359 4.1.2.1. 1361 When operating over UDP, L2TPv3 uses the same port (1701) as L2TPv2 1362 and shares the first two octets of header format with L2TPv2. The 1363 Ver field is used to distinguish L2TPv2 packets from L2TPv3 packets. 1364 If an implementation is capable of operating in L2TPv2 or L2TPv3 1365 modes, it is possible to automatically detect whether a peer can 1366 support L2TPv2 or L2TPv3 and operate accordingly. The details of 1367 this fallback capability is defined in the following section. 1369 4.7.3. Automatic L2TPv2 Fallback 1371 When running over UDP, an implementation may detect whether a peer is 1372 L2TPv3-capable by sending a special SCCRQ that is properly formatted 1373 for both L2TPv2 and L2TPv3. This is accomplished by sending an SCCRQ 1374 with its Ver field set to 2 (for L2TPv2), and ensuring that any 1375 L2TPv3-specific AVPs (i.e., AVPs present within this document and not 1376 defined within RFC 2661) in the message are sent with each M bit set 1377 to 0, and that all L2TPv2 AVPs are present as they would be for 1378 L2TPv2. This is done so that L2TPv3 AVPs will be ignored by an 1379 L2TPv2-only implementation. Note that, in both L2TPv2 and L2TPv3, 1380 the value contained in the space of the control message header 1381 utilized by the 32-bit Control Connection ID in L2TPv3, and the 16- 1382 bit Tunnel ID and 1383 16-bit Session ID in L2TPv2, are always 0 for an SCCRQ. This 1384 effectively hides the fact that there are a pair of 16-bit fields in 1385 L2TPv2, and a single 32-bit field in L2TPv3. 1387 If the peer implementation is L2TPv3-capable, a control message with 1388 the Ver field set to 3 and an L2TPv3 header and message format will 1389 be sent in response to the SCCRQ. Operation may then continue as 1390 L2TPv3. If a message is received with the Ver field set to 2, it 1391 must be assumed that the peer implementation is L2TPv2-only, thus 1392 enabling fallback to L2TPv2 mode to safely occur. 1394 Note Well: The L2TPv2/v3 auto-detection mode requires that all L2TPv3 1395 implementations over UDP be liberal in accepting an SCCRQ control 1396 message with the Ver field set to 2 or 3 and the presence of L2TPv2- 1397 specific AVPs. An L2TPv3-only implementation MUST ignore all L2TPv2 1398 AVPs (e.g., those defined in RFC 2661 and not in this document) 1399 within an SCCRQ with the Ver field set to 2 (even if the M bit is set 1400 on the L2TPv2-specific AVPs). 1402 5. Control Message Attribute Value Pairs 1404 To maximize extensibility while permitting interoperability, a 1405 uniform method for encoding message types is used throughout L2TP. 1406 This encoding will be termed AVP (Attribute Value Pair) for the 1407 remainder of this document. 1409 5.1. AVP Format 1411 Each AVP is encoded as follows: 1413 Figure 5.1: AVP Format 1415 0 1 2 3 1416 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 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 |M|H| rsvd | Length | Vendor ID | 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 | Attribute Type | Attribute Value ... 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 (until Length is reached) | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 The first six bits comprise a bit mask that describes the general 1426 attributes of the AVP. Two bits are defined in this document; the 1427 remaining bits are reserved for future extensions. Reserved bits 1428 MUST be set to 0 when sent and ignored upon receipt. 1430 Mandatory (M) bit: Controls the behavior required of an 1431 implementation that receives an unrecognized AVP. The M bit of a 1432 given AVP MUST only be inspected and acted upon if the AVP is 1433 unrecognized (see Section 5.2). 1435 Hidden (H) bit: Identifies the hiding of data in the Attribute Value 1436 field of an AVP. This capability can be used to avoid the passing of 1437 sensitive data, such as user passwords, as cleartext in an AVP. 1438 Section 5.3 describes the procedure for performing AVP hiding. 1440 Length: Contains the number of octets (including the Overall Length 1441 and bit mask fields) contained in this AVP. The Length may be 1442 calculated as 6 + the length of the Attribute Value field in octets. 1444 The field itself is 10 bits, permitting a maximum of 1023 octets of 1445 data in a single AVP. The minimum Length of an AVP is 6. If the 1446 Length is 6, then the Attribute Value field is absent. 1448 Vendor ID: The IANA-assigned "SMI Network Management Private 1449 Enterprise Codes" [RFC1700] value. The value 0, corresponding to 1450 IETF-adopted attribute values, is used for all AVPs defined within 1451 this document. Any vendor wishing to implement its own L2TP 1452 extensions can use its own Vendor ID along with private Attribute 1453 values, guaranteeing that they will not collide with any other 1454 vendor's extensions or future IETF extensions. Note that there are 1455 16 bits allocated for the Vendor ID, thus limiting this feature to 1456 the first 65,535 enterprises. 1458 Attribute Type: A 2-octet value with a unique interpretation across 1459 all AVPs defined under a given Vendor ID. 1461 Attribute Value: This is the actual value as indicated by the Vendor 1462 ID and Attribute Type. It follows immediately after the Attribute 1463 Type field and runs for the remaining octets indicated in the Length 1464 (i.e., Length minus 6 octets of header). This field is absent if the 1465 Length is 6. 1467 In the event that the 16-bit Vendor ID space is exhausted, vendor- 1468 specific AVPs with a 32-bit Vendor ID MUST be encapsulated in the 1469 following manner: 1471 Figure 5.2: Extended Vendor ID AVP Format 1473 0 1 2 3 1474 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 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 |M|H| rsvd | Length | 0 | 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 | 58 | 32-bit Vendor ID ... 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 | Attribute Type | 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 | Attribute Value ... 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 (until Length is reached) | 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 This AVP encodes a vendor-specific AVP with a 32-bit Vendor ID space 1488 within the Attribute Value field. Multiple AVPs of this type may 1489 exist in any message. The 16-bit Vendor ID MUST be 0, indicating 1490 that this is an IETF-defined AVP, and the Attribute Type MUST be 58, 1491 indicating that what follows is a vendor-specific AVP with a 32-bit 1492 Vendor ID code. This AVP MAY be hidden (the H bit MAY be 0 or 1). 1493 The M bit for this AVP MUST be set to 0. The Length of the AVP is 12 1494 plus the length of the Attribute Value. 1496 5.2. Mandatory AVPs and Setting the M Bit 1498 If the M bit is set on an AVP that is unrecognized by its recipient, 1499 the session or control connection associated with the control message 1500 containing the AVP MUST be shut down. If the control message 1501 containing the unrecognized AVP is associated with a session (e.g., 1502 an ICRQ, ICRP, ICCN, SLI, etc.), then the session MUST be issued a 1503 CDN with a Result Code of 2 and Error Code of 8 (as defined in 1504 Section 5.4.2) and shut down. If the control message containing the 1505 unrecognized AVP is associated with establishment or maintenance of a 1506 Control Connection (e.g., SCCRQ, SCCRP, SCCCN, Hello), then the 1507 associated Control Connection MUST be issued a StopCCN with Result 1508 Code of 2 and Error Code of 8 (as defined in Section 5.4.2) and shut 1509 down. If the M bit is not set on an unrecognized AVP, the AVP MUST 1510 be ignored when received, processing the control message as if the 1511 AVP were not present. 1513 Receipt of an unrecognized AVP that has the M bit set is catastrophic 1514 to the session or control connection with which it is associated. 1515 Thus, the M bit should only be set for AVPs that are deemed crucial 1516 to proper operation of the session or control connection by the 1517 sender. AVPs that are considered crucial by the sender may vary by 1518 application and configured options. In no case shall a receiver of 1519 an AVP "validate" if the M bit is set on a recognized AVP. If the 1520 AVP is recognized (as all AVPs defined in this document MUST be for a 1521 compliant L2TPv3 specification), then by definition, the M bit is of 1522 no consequence. 1524 The sender of an AVP is free to set its M bit to 1 or 0 based on 1525 whether the configured application strictly requires the value 1526 contained in the AVP to be recognized or not. For example, 1527 "Automatic L2TPv2 Fallback" in Section 4.7.3 requires the setting of 1528 the M bit on all new L2TPv3 AVPs to zero if fallback to L2TPv2 is 1529 supported and desired, and 1 if not. 1531 The M bit is useful as extra assurance for support of critical AVP 1532 extensions. However, more explicit methods may be available to 1533 determine support for a given feature rather than using the M bit 1534 alone. For example, if a new AVP is defined in a message for which 1535 there is always a message reply (i.e., an ICRQ, ICRP, SCCRQ, or SCCRP 1536 message), rather than simply sending an AVP in the message with the M 1537 bit set, availability of the extension may be identified by sending 1538 an AVP in the request message and expecting a corresponding AVP in a 1539 reply message. This more explicit method, when possible, is 1540 preferred. 1542 The M bit also plays a role in determining whether or not a malformed 1543 or out-of-range value within an AVP should be ignored or should 1544 result in termination of a session or control connection (see Section 1545 7.1 for more details). 1547 5.3. Hiding of AVP Attribute Values 1549 The H bit in the header of each AVP provides a mechanism to indicate 1550 to the receiving peer whether the contents of the AVP are hidden or 1551 present in cleartext. This feature can be used to hide sensitive 1552 control message data such as user passwords, IDs, or other vital 1553 information. 1555 The H bit MUST only be set if (1) a shared secret exists between the 1556 LCCEs and (2) Control Message Authentication is enabled (see Section 1557 4.3). If the H bit is set in any AVP(s) in a given control message, 1558 at least one Random Vector AVP must also be present in the message 1559 and MUST precede the first AVP having an H bit of 1. 1561 The shared secret between LCCEs is used to derive a unique shared key 1562 for hiding and unhiding calculations. The derived shared key is 1563 obtained via an HMAC-MD5 keyed hash [RFC2104], with the key 1564 consisting of the shared secret, and with the data being hashed 1565 consisting of a single octet containing the value 1. 1567 shared_key = HMAC_MD5 (shared_secret, 1) 1569 Hiding an AVP value is done in several steps. The first step is to 1570 take the length and value fields of the original (cleartext) AVP and 1571 encode them into the Hidden AVP Subformat, which appears as follows: 1573 Figure 5.3: Hidden AVP Subformat 1575 0 1 2 3 1576 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 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | Length of Original Value | Original Attribute Value ... 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 ... | Padding ... 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 Length of Original Attribute Value: This is length of the Original 1584 Attribute Value to be obscured in octets. This is necessary to 1585 determine the original length of the Attribute Value that is lost 1586 when the additional Padding is added. 1588 Original Attribute Value: Attribute Value that is to be obscured. 1590 Padding: Random additional octets used to obscure length of the 1591 Attribute Value that is being hidden. 1593 To mask the size of the data being hidden, the resulting subformat 1594 MAY be padded as shown above. Padding does NOT alter the value 1595 placed in the Length of Original Attribute Value field, but does 1596 alter the length of the resultant AVP that is being created. For 1597 example, if an Attribute Value to be hidden is 4 octets in length, 1598 the unhidden AVP length would be 10 octets (6 + Attribute Value 1599 length). After hiding, the length of the AVP would become 6 + 1600 Attribute Value length + size of the Length of Original Attribute 1601 Value field + Padding. Thus, if Padding is 12 octets, the AVP length 1602 would be 6 + 4 + 2 + 12 = 24 octets. 1604 Next, an MD5 [RFC1321] hash is performed (in network byte order) on 1605 the concatenation of the following: 1607 + the 2-octet Attribute number of the AVP 1608 + the shared key 1609 + an arbitrary length random vector 1611 The value of the random vector used in this hash is passed in the 1612 value field of a Random Vector AVP. This Random Vector AVP must be 1613 placed in the message by the sender before any hidden AVPs. The same 1614 random vector may be used for more than one hidden AVP in the same 1615 message, but not for hiding two or more instances of an AVP with the 1616 same Attribute Type unless the Attribute Values in the two AVPs are 1617 also identical. When a different random vector is used for the 1618 hiding of subsequent AVPs, a new Random Vector AVP MUST be placed in 1619 the control message before the first AVP to which it applies. 1621 The MD5 hash value is then XORed with the first 16-octet (or less) 1622 segment of the Hidden AVP Subformat and placed in the Attribute Value 1623 field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 1624 octets, the Subformat is transformed as if the Attribute Value field 1625 had been padded to 16 octets before the XOR. Only the actual octets 1626 present in the Subformat are modified, and the length of the AVP is 1627 not altered. 1629 If the Subformat is longer than 16 octets, a second one-way MD5 hash 1630 is calculated over a stream of octets consisting of the shared key 1631 followed by the result of the first XOR. That hash is XORed with the 1632 second 16-octet (or less) segment of the Subformat and placed in the 1633 corresponding octets of the Value field of the Hidden AVP. 1635 If necessary, this operation is repeated, with the shared key used 1636 along with each XOR result to generate the next hash to XOR the next 1637 segment of the value with. 1639 The hiding method was adapted from [RFC2865], which was taken from 1640 the "Mixing in the Plaintext" section in the book "Network Security" 1641 by Kaufman, Perlman and Speciner [KPS]. A detailed explanation of 1642 the method follows: 1644 Call the shared key S, the Random Vector RV, and the Attribute Type 1645 A. Break the value field into 16-octet chunks p_1, p_2, etc., with 1646 the last one padded at the end with random data to a 16-octet 1647 boundary. Call the ciphertext blocks c_1, c_2, etc. We will also 1648 define intermediate values b_1, b_2, etc. 1650 b_1 = MD5 (A + S + RV) c_1 = p_1 xor b_1 1651 b_2 = MD5 (S + c_1) c_2 = p_2 xor b_2 1652 . . 1653 . . 1654 . . 1655 b_i = MD5 (S + c_i-1) c_i = p_i xor b_i 1657 The String will contain c_1 + c_2 +...+ c_i, where "+" denotes 1658 concatenation. 1660 On receipt, the random vector is taken from the last Random Vector 1661 AVP encountered in the message prior to the AVP to be unhidden. The 1662 above process is then reversed to yield the original value. 1664 5.4. AVP Summary 1666 The following sections contain a list of all L2TP AVPs defined in 1667 this document. 1669 Following the name of the AVP is a list indicating the message types 1670 that utilize each AVP. After each AVP title follows a short 1671 description of the purpose of the AVP, a detail (including a graphic) 1672 of the format for the Attribute Value, and any additional information 1673 needed for proper use of the AVP. 1675 5.4.1. General Control Message AVPs 1677 Message Type (All Messages) 1679 The Message Type AVP, Attribute Type 0, identifies the control 1680 message herein and defines the context in which the exact meaning 1681 of the following AVPs will be determined. 1683 The Attribute Value field for this AVP has the following format: 1685 0 1 1686 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 | Message Type | 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 The Message Type is a 2-octet unsigned integer. 1693 The Message Type AVP MUST be the first AVP in a message, 1694 immediately following the control message header (defined in 1695 Section 3.2.1). See Section 3.1 for the list of defined control 1696 message types and their identifiers. 1698 The Mandatory (M) bit within the Message Type AVP has special 1699 meaning. Rather than an indication as to whether the AVP itself 1700 should be ignored if not recognized, it is an indication as to 1701 whether the control message itself should be ignored. If the M 1702 bit is set within the Message Type AVP and the Message Type is 1703 unknown to the implementation, the control connection MUST be 1704 cleared. If the M bit is not set, then the implementation may 1705 ignore an unknown message type. The M bit MUST be set to 1 for 1706 all message types defined in this document. This AVP MUST NOT be 1707 hidden (the H bit MUST be 0). The Length of this AVP is 8. 1709 A vendor-specific control message may be defined by setting the 1710 Vendor ID of the Message Type AVP to a value other than the IETF 1711 Vendor ID of 0 (see Section 5.1). The Message Type AVP MUST still 1712 be the first AVP in the control message. 1714 Message Digest (All Messages) 1716 The Message Digest AVP, Attribute Type 59 is used as an integrity 1717 and authentication check of the L2TP Control Message header and 1718 body. 1720 The Attribute Value field for this AVP has the following format: 1722 0 1 2 3 1723 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 | Digest Type | Message Digest ... 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 ... (16 or 20 octets) | 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 Digest Type is a one-octet integer indicating the Digest 1735 calculation algorithm: 1736 0 HMAC-MD5 [RFC2104] 1737 1 HMAC-SHA-1 [RFC2104] 1739 Digest Type 0 (HMAC-MD5) MUST be supported, while Digest Type 1 1740 (HMAC-SHA-1) SHOULD be supported. 1742 The Message Digest is of variable length and contains the result 1743 of the control message authentication and integrity calculation. 1744 For Digest Type 0 (HMAC-MD5), the length of the digest MUST be 16 1745 bytes. For Digest Type 1 (HMAC-SHA-1) the length of the digest 1746 MUST be 20 bytes. 1748 If Control Message Authentication is enabled, at least one Message 1749 Digest AVP MUST be present in all messages and MUST be placed 1750 immediately after the Message Type AVP. This forces the Message 1751 Digest AVP to begin at a well-known and fixed offset. A second 1752 Message Digest AVP MAY be present in a message and MUST be placed 1753 directly after the first Message Digest AVP. 1755 The shared secret between LCCEs is used to derive a unique shared 1756 key for Control Message Authentication calculations. The derived 1757 shared key is obtained via an HMAC-MD5 keyed hash [RFC2104], with 1758 the key consisting of the shared secret, and with the data being 1759 hashed consisting of a single octet containing the value 2. 1761 shared_key = HMAC_MD5 (shared_secret, 2) 1763 Calculation of the Message Digest is as follows for all messages 1764 other than the SCCRQ (where "+" refers to concatenation): 1766 Message Digest = HMAC_Hash (shared_key, local_nonce + 1767 remote_nonce + control_message) 1769 HMAC_Hash: HMAC Hashing algorithm identified by the Digest Type 1770 (MD5 or SHA1) 1772 local_nonce: Nonce chosen locally and advertised to the remote 1773 LCCE. 1775 remote_nonce: Nonce received from the remote LCCE 1777 (The local_nonce and remote_nonce are advertised via the Control 1778 Message Authentication Nonce AVP, also defined in this section.) 1780 shared_key: Derived shared key for this control connection 1782 control_message: The entire contents of the L2TP control message, 1783 including the control message header and all AVPs. Note that the 1784 control message header in this case begins after the all-zero 1785 Session ID when running over IP (see Section 4.1.1.2), and after 1786 the UDP header when running over UDP (see Section 4.1.2.1). 1788 When calculating the Message Digest, the Message Digest AVP MUST be 1789 present within the control message with the Digest Type set to its 1790 proper value, but the Message Digest itself set to zeros. 1792 When receiving a control message, the contents of the Message Digest 1793 AVP MUST be compared against the expected digest value based on local 1794 calculation. This is done by performing the same digest calculation 1795 above, with the local_nonce and remote_nonce reversed. This message 1796 authenticity and integrity checking MUST be performed before 1797 utilizing any information contained within the control message. If 1798 the calculation fails, the message MUST be dropped. 1800 The SCCRQ has special treatment as it is the initial message 1801 commencing a new control connection. As such, there is only one 1802 nonce available. Since the nonce is present within the message 1803 itself as part of the Control Message Authentication Nonce AVP, there 1804 is no need to use it in the calculation explicitly. Calculation of 1805 the SCCRQ Message Digest is performed as follows: 1807 Message Digest = HMAC_Hash (shared_key, control_message) 1809 To allow for graceful switchover to a new shared secret or hash 1810 algorithm, two Message Digest AVPs MAY be present in a control 1811 message, and two shared secrets MAY be configured for a given LCCE. 1812 If two Message Digest AVPs are received in a control message, the 1813 message MUST be accepted if either Message Digest is valid. If two 1814 shared secrets are configured, each (separately) MUST be used for 1815 calculating a digest to be compared to the Message Digest(s) 1816 received. When calculating a digest for a control message, the Value 1817 field for both of the Message Digest AVPs MUST be set to zero. 1819 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1820 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1821 Length is 23 for Digest Type 1 (HMAC-MD5), and 27 for Digest Type 2 1822 (HMAC-SHA-1). 1824 Control Message Authentication Nonce (SCCRQ, SCCRP) 1826 The Control Message Authentication Nonce AVP, Attribute Type 73, 1827 MUST contain a cryptographically random value [RFC1750]. This 1828 value is used for Control Message Authentication. 1830 The Attribute Value field for this AVP has the following format: 1832 0 1 2 3 1833 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 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 | Nonce ... (arbitrary number of octets) 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 The Nonce is of arbitrary length, though at least 16 octets is 1838 recommended. The Nonce contains the random value for use in the 1839 Control Message Authentication hash calculation (see Message 1840 Digest AVP definition in this section). 1842 If Control Message Authentication is enabled, this AVP MUST be 1843 present in the SCCRQ and SCCRP messages. 1845 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1846 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1847 Length of this AVP is 6 plus the length of the Nonce. 1849 Random Vector (All Messages) 1851 The Random Vector AVP, Attribute Type 36, MUST contain a 1852 cryptographically random value [RFC1750]. This value is used for 1853 AVP Hiding. 1855 The Attribute Value field for this AVP has the following format: 1857 0 1 2 3 1858 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 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | Random Octet String ... (arbitrary number of octets) 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 The Random Octet String is of arbitrary length, though at least 16 1864 octets is recommended. The string contains the random vector for 1865 use in computing the MD5 hash to retrieve or hide the Attribute 1866 Value of a hidden AVP (see Section 5.3). 1868 More than one Random Vector AVP may appear in a message, in which 1869 case a hidden AVP uses the Random Vector AVP most closely 1870 preceding it. As such, at least one Random Vector AVP MUST 1871 precede the first AVP with the H bit set. 1873 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1874 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1875 Length of this AVP is 6 plus the length of the Random Octet 1876 String. 1878 5.4.2. Result and Error Codes 1880 Result Code (StopCCN, CDN) 1882 The Result Code AVP, Attribute Type 1, indicates the reason for 1883 terminating the control connection or session. 1885 The Attribute Value field for this AVP has the following format: 1887 0 1 2 3 1888 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 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | Result Code | Error Code (optional) | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | Error Message ... (optional, arbitrary number of octets) | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 The Result Code is a 2-octet unsigned integer. The optional Error 1896 Code is a 2-octet unsigned integer. An optional Error Message can 1897 follow the Error Code field. Presence of the Error Code and 1898 Message is indicated by the AVP Length field. The Error Message 1899 contains an arbitrary string providing further (human-readable) 1900 text associated with the condition. Human-readable text in all 1901 error messages MUST be provided in the UTF-8 charset [RFC3629] 1902 using the Default Language [RFC2277]. 1904 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 1905 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 1906 Length is 8 if there is no Error Code or Message, 10 if there is 1907 an Error Code and no Error Message, or 10 plus the length of the 1908 Error Message if there is an Error Code and Message. 1910 Defined Result Code values for the StopCCN message are as follows: 1912 0 - Reserved. 1913 1 - General request to clear control connection. 1914 2 - General error, Error Code indicates the problem. 1915 3 - Control connection already exists. 1916 4 - Requester is not authorized to establish a control connection. 1917 5 - The protocol version of the requester is not supported, 1918 Error Code indicates highest version supported. 1919 6 - Requester is being shut down. 1920 7 - Finite state machine error or timeout 1922 General Result Code values for the CDN message are as follows: 1924 0 - Reserved. 1925 1 - Session disconnected due to loss of carrier or 1926 circuit disconnect. 1927 2 - Session disconnected for the reason indicated in Error 1928 Code. 1929 3 - Session disconnected for administrative reasons. 1930 4 - Session establishment failed due to lack of appropriate 1931 facilities being available (temporary condition). 1933 5 - Session establishment failed due to lack of appropriate 1934 facilities being available (permanent condition). 1935 6 - 11 Reserved 1936 13 - Session not established due to losing tie breaker. 1937 14 - Session not established due to unsupported PW type. 1938 15 - Session not established, sequencing required without 1939 valid L2-Specific Sublayer. 1940 16 - Finite state machine error or timeout. 1942 Additional service-specific Result Codes are defined outside this 1943 document. 1945 The Error Codes defined below pertain to types of errors that are 1946 not specific to any particular L2TP request, but rather to 1947 protocol or message format errors. If an L2TP reply indicates in 1948 its Result Code that a General Error occurred, the General Error 1949 value should be examined to determine what the error was. The 1950 currently defined General Error codes and their meanings are as 1951 follows: 1953 0 - No General Error. 1954 1 - No control connection exists yet for this pair of LCCEs. 1955 2 - Length is wrong. 1956 3 - One of the field values was out of range. 1957 4 - Insufficient resources to handle this operation now. 1958 5 - Invalid Session ID. 1959 6 - A generic vendor-specific error occurred. 1960 7 - Try another. If initiator is aware of other possible 1961 responder destinations, it should try one of them. This can 1962 be used to guide an LAC or LNS based on policy. 1963 8 - The session or control connection was shut down due to receipt 1964 of an unknown AVP with the M bit set (see Section 5.2). The 1965 Error Message SHOULD contain the attribute of the offending 1966 AVP in (human-readable) text form. 1967 9 - Try another directed. If an LAC or LNS is aware of other 1968 possible destinations, it should inform the initiator of the 1969 control connection or session. The Error Message MUST contain 1970 a comma-separated list of addresses from which the initiator 1971 may choose. If the L2TP data channel runs over IPv4, then 1972 this would be a comma-separated list of IP addresses in the 1973 canonical dotted-decimal format (e.g., "192.0.2.1, 192.0.2.2, 1974 192.0.2.3") in the UTF-8 charset [RFC3629] using the Default 1975 Language [RFC2277]. If there are no servers for the LAC or 1976 LNS to suggest, then Error Code 7 should be used. For IPv4, 1977 the delimiter between addresses MUST be precisely a single 1978 comma and a single space. For IPv6, each literal address MUST 1979 be enclosed in "[" and "]" characters, following the encoding 1980 described in [RFC2732]. 1982 When a General Error Code of 6 is used, additional information 1983 about the error SHOULD be included in the Error Message field. A 1984 vendor-specific AVP MAY be sent to more precisely detail a 1985 vendor-specific problem. 1987 5.4.3. Control Connection Management AVPs 1989 Control Connection Tie Breaker (SCCRQ) 1991 The Control Connection Tie Breaker AVP, Attribute Type 5, 1992 indicates that the sender desires a single control connection to 1993 exist between a given pair of LCCEs. 1995 The Attribute Value field for this AVP has the following format: 1997 0 1 2 3 1998 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 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 | Control Connection Tie Breaker Value ... 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 ... (64 bits) | 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 The Control Connection Tie Breaker Value is an 8-octet random 2006 value that is used to choose a single control connection when two 2007 LCCEs request a control connection concurrently. The recipient of 2008 a SCCRQ must check to see if a SCCRQ has been sent to the peer; if 2009 so, a tie has been detected. In this case, the LCCE must compare 2010 its Control Connection Tie Breaker value with the one received in 2011 the SCCRQ. The lower value "wins", and the "loser" MUST discard 2012 its control connection. A StopCCN SHOULD be sent by the winner as 2013 an explicit rejection for the losing SCCRQ. In the case in which 2014 a tie breaker is present on both sides and the value is equal, 2015 both sides MUST discard their control connections and restart 2016 control connection negotiation with a new, random tie breaker 2017 value. 2019 If a tie breaker is received and an outstanding SCCRQ has no tie 2020 breaker value, the initiator that included the Control Connection 2021 Tie Breaker AVP "wins". If neither side issues a tie breaker, 2022 then two separate control connections are opened. 2024 Applications that employ a distinct and well-known initiator have 2025 no need for tie breaking, and MAY omit this AVP or disable tie 2026 breaking functionality. Applications that require tie breaking 2027 also require that an LCCE be uniquely identifiable upon receipt of 2028 an SCCRQ. For L2TP over IP, this MUST be accomplished via the 2029 Router ID AVP. 2031 Note that in [RFC2661], this AVP is referred to as the "Tie 2032 Breaker AVP" and is applicable only to a control connection. In 2033 L2TPv3, the AVP serves the same purpose of tie breaking, but is 2034 applicable to a control connection or a session. The Control 2035 Connection Tie Breaker AVP (present only in Control Connection 2036 messages) and Session Tie Breaker AVP (present only in Session 2037 messages), are described separately in this document, but share 2038 the same Attribute type of 5. 2040 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 2041 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2042 length of this AVP is 14. 2044 Host Name (SCCRQ, SCCRP) 2046 The Host Name AVP, Attribute Type 7, indicates the name of the 2047 issuing LAC or LNS, encoded in the US-ASCII charset. 2049 The Attribute Value field for this AVP has the following format: 2051 0 1 2 3 2052 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 2053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2054 | Host Name ... (arbitrary number of octets) 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 The Host Name is of arbitrary length, but MUST be at least 1 2058 octet. 2060 This name should be as broadly unique as possible; for hosts 2061 participating in DNS [RFC1034], a host name with fully qualified 2062 domain would be appropriate. The Host Name AVP and/or Router ID 2063 AVP MUST be used to identify an LCCE as described in Section 3.3. 2065 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 2066 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2067 Length of this AVP is 6 plus the length of the Host Name. 2069 Router ID (SCCRQ, SCCRP) 2071 The Router ID AVP, Attribute Type 60, is an identifier used to 2072 identify an LCCE for control connection setup, tie breaking, 2073 and/or tunnel authentication. 2075 The Attribute Value field for this AVP has the following format: 2077 0 1 2 3 2078 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 | Router Identifier | 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 The Router Identifier is a 4-octet unsigned integer. Its value is 2085 unique for a given LCCE, per Section 8.1 of [RFC2072]. The Host 2086 Name AVP and/or Router ID AVP MUST be used to identify an LCCE as 2087 described in Section 3.3. 2089 Implementations MUST NOT assume that Router Identifier is a valid 2090 IP address. The Router Identifier for L2TP over IPv6 can be 2091 obtained from an IPv4 address (if available) or via unspecified 2092 implementation-specific means. 2094 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 2095 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2096 Length of this AVP is 10. 2098 Vendor Name (SCCRQ, SCCRP) 2100 The Vendor Name AVP, Attribute Type 8, contains a vendor-specific 2101 (possibly human-readable) string describing the type of LAC or LNS 2102 being used. 2104 The Attribute Value field for this AVP has the following format: 2106 0 1 2 3 2107 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 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | Vendor Name ... (arbitrary number of octets) 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 The Vendor Name is the indicated number of octets representing the 2113 vendor string. Human-readable text for this AVP MUST be provided 2114 in the US-ASCII charset [RFC1958, RFC2277]. 2116 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for 2117 this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The 2118 Length (before hiding) of this AVP is 6 plus the length of the 2119 Vendor Name. 2121 Assigned Control Connection ID (SCCRQ, SCCRP, StopCCN) 2123 The Assigned Control Connection ID AVP, Attribute Type 61, 2124 contains the ID being assigned to this control connection by the 2125 sender. 2127 The Attribute Value field for this AVP has the following format: 2129 0 1 2 3 2130 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 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | Assigned Control Connection ID | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 The Assigned Control Connection ID is a 4-octet non-zero unsigned 2136 integer. 2138 The Assigned Control Connection ID AVP establishes the identifier 2139 used to multiplex and demultiplex multiple control connections 2140 between a pair of LCCEs. Once the Assigned Control Connection ID 2141 AVP has been received by an LCCE, the Control Connection ID 2142 specified in the AVP MUST be included in the Control Connection ID 2143 field of all control packets sent to the peer for the lifetime of 2144 the control connection. Before the Assigned Control Connection ID 2145 AVP is received from a peer, all control messages MUST be sent to 2146 that peer with a Control Connection ID value of 0 in the header. 2147 Because a Control Connection ID value of 0 is used in this special 2148 manner, the zero value MUST NOT be sent as an Assigned Control 2149 Connection ID value. 2151 Under certain circumstances, an LCCE may need to send a StopCCN to 2152 a peer without having yet received an Assigned Control Connection 2153 ID AVP from the peer (i.e., SCCRQ sent, no SCCRP received yet). 2154 In this case, the Assigned Control Connection ID AVP that had been 2155 sent to the peer earlier (i.e., in the SCCRQ) MUST be sent as the 2156 Assigned Control Connection ID AVP in the StopCCN. This policy 2157 allows the peer to try to identify the appropriate control 2158 connection via a reverse lookup. 2160 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for 2161 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2162 Length (before hiding) of this AVP is 10. 2164 Receive Window Size (SCCRQ, SCCRP) 2166 The Receive Window Size AVP, Attribute Type 10, specifies the 2167 receive window size being offered to the remote peer. 2169 The Attribute Value field for this AVP has the following format: 2171 0 1 2172 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | Window Size | 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 The Window Size is a 2-octet unsigned integer. 2178 If absent, the peer must assume a Window Size of 4 for its 2179 transmit window. 2181 The remote peer may send the specified number of control messages 2182 before it must wait for an acknowledgment. See Section 4.2 for 2183 more information on reliable control message delivery. 2185 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 2186 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2187 Length of this AVP is 8. 2189 Pseudowire Capabilities List (SCCRQ, SCCRP) 2191 The Pseudowire Capabilities List (PW Capabilities List) AVP, 2192 Attribute Type 62, indicates the L2 payload types the sender can 2193 support. The specific payload type of a given session is 2194 identified by the Pseudowire Type AVP. 2196 The Attribute Value field for this AVP has the following format: 2198 0 1 2 3 2199 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 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 | PW Type 0 | ... | 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 | ... | PW Type N | 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 Defined PW types that may appear in this list are managed by IANA 2207 and will appear in associated pseudowire-specific documents for 2208 each PW type. 2210 If a sender includes a given PW type in the PW Capabilities List 2211 AVP, the sender assumes full responsibility for supporting that 2212 particular payload, such as any payload-specific AVPs, L2-Specific 2213 Sublayer, or control messages that may be defined in the 2214 appropriate companion document. 2216 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for 2217 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2218 Length (before hiding) of this AVP is 8 octets with one PW type 2219 specified, plus 2 octets for each additional PW type. 2221 Preferred Language (SCCRQ, SCCRP) 2223 The Preferred Language AVP, Attribute Type 72, provides a method 2224 for an LCCE to indicate to the peer the language in which human- 2225 readable messages it sends SHOULD be composed. This AVP contains 2226 a single language tag or language range [RFC3066]. 2228 The Attribute Value field for this AVP has the following format: 2230 0 1 2 3 2231 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 2232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2233 | Preferred Language... (arbitrary number of octets) 2234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 The Preferred Language is the indicated number of octets 2237 representing the language tag or language range, encoded in the 2238 US-ASCII charset. 2240 It is not required to send a Preferred Language AVP. If (1) an 2241 LCCE does not signify a language preference by the inclusion of 2242 this AVP in the SCCRQ or SCCRP, (2) the Preferred Language AVP is 2243 unrecognized, or (3) the requested language is not supported by 2244 the peer LCCE, the default language [RFC2277] MUST be used for all 2245 internationalized strings sent by the peer. 2247 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for 2248 this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The 2249 Length (before hiding) of this AVP is 6 plus the length of the 2250 Preferred Language. 2252 5.4.4. Session Management AVPs 2254 Local Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI) 2256 The Local Session ID AVP (analogous to the Assigned Session ID in 2257 L2TPv2), Attribute Type 63, contains the identifier being assigned 2258 to this session by the sender. 2260 The Attribute Value field for this AVP has the following format: 2262 0 1 2 3 2263 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 2264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 | Local Session ID | 2266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2268 The Local Session ID is a 4-octet non-zero unsigned integer. 2270 The Local Session ID AVP establishes the two identifiers used to 2271 multiplex and demultiplex sessions between two LCCEs. Each LCCE 2272 chooses any free value it desires, and sends it to the remote LCCE 2273 using this AVP. The remote LCCE MUST then send all data packets 2274 associated with this session using this value. Additionally, for 2275 all session-oriented control messages sent after this AVP is 2276 received (e.g., ICRP, ICCN, CDN, SLI, etc.), the remote LCCE MUST 2277 echo this value in the Remote Session ID AVP. 2279 Note that a Session ID value is unidirectional. Because each LCCE 2280 chooses its Session ID independent of its peer LCCE, the value 2281 does not have to match in each direction for a given session. 2283 See Section 4.1 for additional information about the Session ID. 2285 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for 2286 this AVP SHOULD be 1 set to 1, but MAY vary (see Section 5.2). 2287 The Length (before hiding) of this AVP is 10. 2289 Remote Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI) 2291 The Remote Session ID AVP, Attribute Type 64, contains the 2292 identifier that was assigned to this session by the peer. 2294 The Attribute Value field for this AVP has the following format: 2296 0 1 2 3 2297 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 2298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2299 | Remote Session ID | 2300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2302 The Remote Session ID is a 4-octet non-zero unsigned integer. 2304 The Remote Session ID AVP MUST be present in all session-level 2305 control messages. The AVP's value echoes the session identifier 2306 advertised by the peer via the Local Session ID AVP. It is the 2307 same value that will be used in all transmitted data messages by 2308 this side of the session. In most cases, this identifier is 2309 sufficient for the peer to look up session-level context for this 2310 control message. 2312 When a session-level control message must be sent to the peer 2313 before the Local Session ID AVP has been received, the value of 2314 the Remote Session ID AVP MUST be set to zero. Additionally, the 2315 Local Session ID AVP (sent in a previous control message for this 2316 session) MUST be included in the control message. The peer must 2317 then use the Local Session ID AVP to perform a reverse lookup to 2318 find its session context. Session-level control messages defined 2319 in this document that might be subject to a reverse lookup by a 2320 receiving peer include the CDN, WEN, and SLI. 2322 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for 2323 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2324 Length (before hiding) of this AVP is 10. 2326 Assigned Cookie (ICRQ, ICRP, OCRQ, OCRP) 2328 The Assigned Cookie AVP, Attribute Type 65, contains the Cookie 2329 value being assigned to this session by the sender. 2331 The Attribute Value field for this AVP has the following format: 2333 0 1 2 3 2334 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 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 | Assigned Cookie (32 or 64 bits) ... 2337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2339 The Assigned Cookie is a 4-octet or 8-octet random value. 2341 The Assigned Cookie AVP contains the value used to check the 2342 association of a received data message with the session identified 2343 by the Session ID. All data messages sent to a peer MUST use the 2344 Assigned Cookie sent by the peer in this AVP. The value's length 2345 (0, 32, or 64 bits) is obtained by the length of the AVP. 2347 A missing Assigned Cookie AVP or Assigned Cookie Value of zero 2348 length indicates that the Cookie field should not be present in 2349 any data packets sent to the LCCE sending this AVP. 2351 See Section 4.1 for additional information about the Assigned 2352 Cookie. 2354 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for 2355 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2356 Length (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 2375 set to progressively increasing values, which are likely to be 2376 unique for a significant period of time across all interconnected 2377 LNSs and LACs. 2379 Note that in RFC 2661, this value was referred to as the "Call 2380 Serial Number AVP". It serves the same purpose and has the same 2381 attribute value and composition. 2383 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for 2384 this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The 2385 Length (before hiding) of this AVP is 10. 2387 Remote End ID (ICRQ, OCRQ) 2389 The Remote End ID AVP, Attribute Type 66, contains an identifier 2390 used to bind L2TP sessions to a given circuit, interface, or 2391 bridging instance. It also may be used to detect session-level 2392 ties. 2394 The Attribute Value field for this AVP has the following format: 2396 0 1 2 3 2397 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 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 | Remote End Identifier ... (arbitrary number of octets) 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2402 The Remote End Identifier field is a variable-length field whose 2403 value is unique for a given LCCE peer, as described in Section 2404 3.3. 2406 A session-level tie is detected if an LCCE receives an ICRQ or 2407 OCRQ with an End ID AVP whose value matches that which was just 2408 sent in an outgoing ICRQ or OCRQ to the same peer. If the two 2409 values match, an LCCE recognizes that a tie exists (i.e., both 2410 LCCEs are attempting to establish sessions for the same circuit). 2411 The tie is broken by the Session Tie Breaker AVP. 2413 By default, the LAC-LAC cross-connect application (see Section 2414 2(b)) of L2TP over an IP network MUST utilize the Router ID AVP 2415 and Remote End ID AVP to associate a circuit to an L2TP session. 2416 Other AVPs MAY be used for LCCE or circuit identification as 2417 specified in companion documents. 2419 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for 2420 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2421 Length (before hiding) of this AVP is 6 plus the length of the 2422 Remote End Identifier value. 2424 Session Tie Breaker (ICRQ, OCRQ) 2426 The Session Tie Breaker AVP, Attribute Type 5, is used to break ties 2427 when two peers concurrently attempt to establish a session for the 2428 same circuit. 2430 The Attribute Value field for this AVP has the following format: 2432 0 1 2 3 2433 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 2434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2435 | Session Tie Breaker Value ... 2436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2437 ... (64 bits) | 2438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2440 The Session Tie Breaker Value is an 8-octet random value that is used 2441 to choose a session when two LCCEs concurrently request a session for 2442 the same circuit. A tie is detected by examining the peer's identity 2443 (described in Section 3.3) plus the per-session shared value 2444 communicated via the End ID AVP. In the case of a tie, the recipient 2445 of an ICRQ or OCRQ must compare the received tie breaker value with 2446 the one that it sent earlier. The LCCE with the lower value "wins" 2447 and MUST send a CDN with result code set to 13 (as defined in Section 2448 5.4.2) in response to the losing ICRQ or OCRQ. In the case in which a 2449 tie is detected, tie breakers are sent by both sides, and the tie 2450 breaker values are equal, both sides MUST discard their sessions and 2451 restart session negotiation with new random tie breaker values. 2453 If a tie is detected but only one side sends a Session Tie Breaker 2454 AVP, the session initiator that included the Session Tie Breaker AVP 2455 "wins". If neither side issues a tie breaker, then both sides MUST 2456 tear down the session. 2458 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 2459 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2460 Length of this AVP is 14. 2462 Pseudowire Type (ICRQ, OCRQ) 2464 The Pseudowire Type (PW Type) AVP, Attribute Type 68, indicates 2465 the L2 payload type of the packets that will be tunneled using 2466 this L2TP session. 2468 The Attribute Value field for this AVP has the following format: 2470 0 1 2471 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2473 | PW Type | 2474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 A peer MUST NOT request an incoming or outgoing call with a PW 2477 Type AVP specifying a value not advertised in the PW Capabilities 2478 List AVP it received during control connection establishment. 2479 Attempts to do so MUST result in the call being rejected via a CDN 2480 with the Result Code set to 14 (see Section 5.4.2). 2482 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for 2483 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2484 Length (before hiding) of this AVP is 8. 2486 L2-Specific Sublayer (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2488 The L2-Specific Sublayer AVP, Attribute Type 69, indicates the 2489 presence and format of the L2-Specific Sublayer the sender of this 2490 AVP requires on all incoming data packets for this L2TP session. 2492 0 1 2493 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2495 | L2-Specific Sublayer Type | 2496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2498 The L2-Specific Sublayer Type is a 2-octet unsigned integer with the 2499 following values defined in this document: 2501 0 - There is no L2-Specific Sublayer present. 2502 1 - The Default L2-Specific Sublayer (defined in Section 4.6) 2503 is used. 2505 If this AVP is received and has a value other than zero, the 2506 receiving LCCE MUST include the identified L2-Specific Sublayer in 2507 its outgoing data messages. If the AVP is not received, it is 2508 assumed that there is no sublayer present. 2510 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2511 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2512 (before hiding) of this AVP is 8. 2514 Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2516 The Data Sequencing AVP, Attribute Type 70, indicates that the 2517 sender requires some or all of the data packets that it receives 2518 to be sequenced. 2520 The Attribute Value field for this AVP has the following format: 2522 0 1 2523 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 | Data Sequencing Level | 2526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 The Data Sequencing Level is a 2-octet unsigned integer indicating 2529 the degree of incoming data traffic that the sender of this AVP 2530 wishes to be marked with sequence numbers. 2532 Defined Data Sequencing Levels are as follows: 2534 0 - No incoming data packets require sequencing. 2535 1 - Only non-IP data packets require sequencing. 2536 2 - All incoming data packets require sequencing. 2538 If a Data Sequencing Level of 0 is specified, there is no need to 2539 send packets with sequence numbers. If sequence numbers are sent, 2540 they will be ignored upon receipt. If no Data Sequencing AVP is 2541 received, a Data Sequencing Level of 0 is assumed. 2543 If a Data Sequencing Level of 1 is specified, only non-IP traffic 2544 carried within the tunneled L2 frame should have sequence numbers 2545 applied. Non-IP traffic here refers to any packets that cannot be 2546 classified as an IP packet within their respective L2 framing (e.g., 2547 a PPP control packet or NETBIOS frame encapsulated by Frame Relay 2548 before being tunneled). All traffic that can be classified as IP 2549 MUST be sent with no sequencing (i.e., the S bit in the L2-Specific 2550 Sublayer is set to zero). If a packet is unable to be classified at 2551 all (e.g., because it has been compressed or encrypted at layer 2) or 2552 if an implementation is unable to perform such classification within 2553 L2 frames, all packets MUST be provided with sequence numbers 2554 (essentially falling back to a Data Sequencing Level of 2). 2556 If a Data Sequencing Level of 2 is specified, all traffic MUST be 2557 sequenced. 2559 Data sequencing may only be requested when there is an L2-Specific 2560 Sublayer present that can provide sequence numbers. If sequencing is 2561 requested without requesting a L2-Specific Sublayer AVP, the session 2562 MUST be disconnected with a Result Code of 15 (see Section 5.4.2). 2564 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 2565 AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length 2566 (before hiding) of this AVP is 8. 2568 Tx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2570 The Tx Connect Speed BPS AVP, Attribute Type 74, contains the 2571 speed of the facility chosen for the connection attempt. 2573 The Attribute Value field for this AVP has the following format: 2575 0 1 2 3 2576 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 2577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 | Connect Speed in bps... 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2580 ...Connect Speed in bps (64 bits) | 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 The Tx Connect Speed BPS is an 8-octet value indicating the speed 2584 in bits per second. A value of zero indicates that the speed is 2585 indeterminable or that there is no physical point-to-point link. 2587 When the optional Rx Connect Speed AVP is present, the value in 2588 this AVP represents the transmit connect speed from the 2589 perspective of the LAC (i.e., data flowing from the LAC to the 2590 remote system). When the optional Rx Connect Speed AVP is NOT 2591 present, the connection speed between the remote system and LAC is 2592 assumed to be symmetric and is represented by the single value in 2593 this AVP. 2595 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for 2596 this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The 2597 Length (before hiding) of this AVP is 14. 2599 Rx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 2601 The Rx Connect Speed AVP, Attribute Type 75, represents the speed 2602 of the connection from the perspective of the LAC (i.e., data 2603 flowing from the remote system to the LAC). 2605 The Attribute Value field for this AVP has the following format: 2607 0 1 2 3 2608 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 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 | Connect Speed in bps... 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2612 ...Connect Speed in bps (64 bits) | 2613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 Connect Speed BPS is an 8-octet value indicating the speed in bits 2616 per second. A value of zero indicates that the speed is 2617 indeterminable or that there is no physical point-to-point link. 2619 Presence of this AVP implies that the connection speed may be 2620 asymmetric with respect to the transmit connect speed given in the 2621 Tx Connect Speed AVP. 2623 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for 2624 this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The 2625 Length (before hiding) of this AVP is 14. 2627 Physical Channel ID (ICRQ, ICRP, OCRP) 2629 The Physical Channel ID AVP, Attribute Type 25, contains the 2630 vendor-specific physical channel number used for a call. 2632 The Attribute Value field for this AVP has the following format: 2634 0 1 2 3 2635 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 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 | Physical Channel ID | 2638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2640 Physical Channel ID is a 4-octet value intended to be used for 2641 logging purposes only. 2643 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for 2644 this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The 2645 Length (before hiding) of this AVP is 10. 2647 5.4.5. Circuit Status AVPs 2649 Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI) 2651 The Circuit Status AVP, Attribute Type 71, indicates the initial 2652 status of or a status change in the circuit to which the session 2653 is bound. 2655 The Attribute Value field for this AVP has the following format: 2657 0 1 2658 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2660 | Reserved |N|A| 2661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2663 The A (Active) bit indicates whether the circuit is 2664 up/active/ready (1) or down/inactive/not-ready (0). 2666 The N (New) bit indicates whether the circuit status indication is 2667 for a new circuit (1) or an existing circuit (0). Links that have 2668 a similar mechanism available (e.g., Frame Relay) MUST map the 2669 setting of this bit to the associated signaling for that link. 2670 Otherwise, the New bit SHOULD still be set the first time the L2TP 2671 session is established after provisioning. 2673 The remaining bits are reserved for future use. Reserved bits 2674 MUST be set to 0 when sending and ignored upon receipt. 2676 The Circuit Status AVP is used to advertise whether a circuit or 2677 interface bound to an L2TP session is up and ready to send and/or 2678 receive traffic. Different circuit types have different names for 2679 status types. For example, HDLC primary and secondary stations 2680 refer to a circuit as being "Receive Ready" or "Receive Not 2681 Ready", while Frame Relay refers to a circuit as "Active" or 2682 "Inactive". This AVP adopts the latter terminology, though the 2683 concept remains the same regardless of the PW type for the L2TP 2684 session. 2686 In the simplest case, the circuit to which this AVP refers is a 2687 single physical interface, port, or circuit, depending on the 2688 application and the session setup. The status indication in this 2689 AVP may then be used to provide simple ILMI interworking for a 2690 variety of circuit types. For virtual or multipoint interfaces, 2691 the Circuit Status AVP is still utilized, but in this case, it 2692 refers to the state of an internal structure or a logical set of 2693 circuits. Each PW-specific companion document MUST specify 2694 precisely how this AVP is translated for each circuit type. 2696 If this AVP is received with a Not Active notification for a given 2697 L2TP session, all data traffic for that session MUST cease (or not 2698 begin) in the direction of the sender of the Circuit Status AVP 2699 until the circuit is advertised as Active. 2701 The Circuit Status MUST be advertised by this AVP in ICRQ, ICRP, 2702 OCRQ, and OCRP messages. Often, the circuit type will be marked 2703 Active when initiated, but subsequently MAY be advertised as 2704 Inactive. This indicates that an L2TP session is to be created, 2705 but that the interface or circuit is still not ready to pass 2706 traffic. The ICCN, OCCN, and SLI control messages all MAY contain 2707 this AVP to update the status of the circuit after establishment 2708 of the L2TP session is requested. 2710 If additional circuit status information is needed for a given PW 2711 type, any new PW-specific AVPs MUST be defined in a separate 2712 document. This AVP is only for general circuit status information 2713 generally applicable to all circuit/interface types. 2715 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for 2716 this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The 2717 Length (before hiding) of this AVP is 8. 2719 Circuit Errors (WEN) 2721 The Circuit Errors AVP, Attribute Type 34, conveys circuit error 2722 information to the peer. 2724 The Attribute Value field for this AVP has the following format: 2726 0 1 2 3 2727 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 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2729 | Reserved | 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2731 | Hardware Overruns | 2732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2733 | Buffer Overruns | 2734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2735 | Timeout Errors | 2736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2737 | Alignment Errors | 2738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2740 The following fields are defined: 2742 Reserved: 2 octets of Reserved data is present (providing longword 2743 alignment within the AVP of the following values). Reserved 2744 data MUST be zero on sending and ignored upon receipt. 2745 Hardware Overruns: Number of receive buffer overruns since call 2746 was established. 2747 Buffer Overruns: Number of buffer overruns detected since call was 2748 established. 2749 Timeout Errors: Number of timeouts since call was established. 2750 Alignment Errors: Number of alignment errors since call was 2751 established. 2753 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for 2754 this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The 2755 Length (before hiding) of this AVP is 32. 2757 6. Control Connection Protocol Specification 2759 The following control messages are used to establish, maintain, and 2760 tear down L2TP control connections. All data packets are sent in 2761 network order (high-order octets first). Any "reserved" or "empty" 2762 fields MUST be sent as 0 values to allow for protocol extensibility. 2764 The exchanges in which these messages are involved are outlined in 2765 Section 3.3. 2767 6.1. Start-Control-Connection-Request (SCCRQ) 2769 Start-Control-Connection-Request (SCCRQ) is a control message used to 2770 initiate a control connection between two LCCEs. It is sent by 2771 either the LAC or the LNS to begin the control connection 2772 establishment process. 2774 The following AVPs MUST be present in the SCCRQ: 2776 Message Type 2777 Host Name 2778 Router ID 2779 Assigned Control Connection ID 2780 Pseudowire Capabilities List 2782 The following AVPs MAY be present in the SCCRQ: 2784 Random Vector 2785 Control Message Authentication Nonce 2786 Message Digest 2787 Control Connection Tie Breaker 2788 Vendor Name 2789 Receive Window Size 2790 Preferred Language 2792 6.2. Start-Control-Connection-Reply (SCCRP) 2794 Start-Control-Connection-Reply (SCCRP) is the control message sent in 2795 reply to a received SCCRQ message. The SCCRP is used to indicate 2796 that the SCCRQ was accepted and that establishment of the control 2797 connection should continue. 2799 The following AVPs MUST be present in the SCCRP: 2801 Message Type 2802 Host Name 2803 Router ID 2804 Assigned Control Connection ID 2805 Pseudowire Capabilities List 2807 The following AVPs MAY be present in the SCCRP: 2809 Random Vector 2810 Control Message Authentication Nonce 2811 Message Digest 2812 Vendor Name 2813 Receive Window Size 2814 Preferred Language 2816 6.3. Start-Control-Connection-Connected (SCCCN) 2818 Start-Control-Connection-Connected (SCCCN) is the control message 2819 sent in reply to an SCCRP. The SCCCN completes the control 2820 connection establishment process. 2822 The following AVP MUST be present in the SCCCN: 2824 Message Type 2826 The following AVP MAY be present in the SCCCN: 2828 Random Vector 2829 Message Digest 2831 6.4. Stop-Control-Connection-Notification (StopCCN) 2833 Stop-Control-Connection-Notification (StopCCN) is the control message 2834 sent by either LCCE to inform its peer that the control connection is 2835 being shut down and that the control connection should be closed. In 2836 addition, all active sessions are implicitly cleared (without sending 2837 any explicit session control messages). The reason for issuing this 2838 request is indicated in the Result Code AVP. There is no explicit 2839 reply to the message, only the implicit ACK that is received by the 2840 reliable control message delivery layer. 2842 The following AVPs MUST be present in the StopCCN: 2844 Message Type 2845 Result Code 2847 The following AVPs MAY be present in the StopCCN: 2849 Random Vector 2850 Message Digest 2851 Assigned Control Connection ID 2853 Note that the Assigned Control Connection ID MUST be present if the 2854 StopCCN is sent after an SCCRQ or SCCRP message has been sent. 2856 6.5. Hello (HELLO) 2858 The Hello (HELLO) message is an L2TP control message sent by either 2859 peer of a control connection. This control message is used as a 2860 "keepalive" for the control connection. See Section 4.2 for a 2861 description of the keepalive mechanism. 2863 HELLO messages are global to the control connection. The Session ID 2864 in a HELLO message MUST be 0. 2866 The following AVP MUST be present in the HELLO: 2868 Message Type 2870 The following AVP MAY be present in the HELLO: 2872 Random Vector 2873 Message Digest 2875 6.6. Incoming-Call-Request (ICRQ) 2877 Incoming-Call-Request (ICRQ) is the control message sent by an LCCE 2878 to a peer when an incoming call is detected (although the ICRQ may 2879 also be sent as a result of a local event). It is the first in a 2880 three-message exchange used for establishing a session via an L2TP 2881 control connection. 2883 The ICRQ is used to indicate that a session is to be established 2884 between an LCCE and a peer. The sender of an ICRQ provides the peer 2885 with parameter information for the session. However, the sender 2886 makes no demands about how the session is terminated at the peer 2887 (i.e., whether the L2 traffic is processed locally, forwarded, etc.). 2889 The following AVPs MUST be present in the ICRQ: 2891 Message Type 2892 Local Session ID 2893 Remote Session ID 2894 Serial Number 2895 Pseudowire Type 2896 Remote End ID 2897 Circuit Status 2899 The following AVPs MAY be present in the ICRQ: 2901 Random Vector 2902 Message Digest 2903 Assigned Cookie 2904 Session Tie Breaker 2905 L2-Specific Sublayer 2906 Data Sequencing 2907 Tx Connect Speed 2908 Rx Connect Speed 2909 Physical Channel ID 2911 6.7. Incoming-Call-Reply (ICRP) 2913 Incoming-Call-Reply (ICRP) is the control message sent by an LCCE in 2914 response to a received ICRQ. It is the second in the three-message 2915 exchange used for establishing sessions within an L2TP control 2916 connection. 2918 The ICRP is used to indicate that the ICRQ was successful and that 2919 the peer should establish (i.e., answer) the incoming call if it has 2920 not already done so. It also allows the sender to indicate specific 2921 parameters about the L2TP session. 2923 The following AVPs MUST be present in the ICRP: 2925 Message Type 2926 Local Session ID 2927 Remote Session ID 2928 Circuit Status 2930 The following AVPs MAY be present in the ICRP: 2932 Random Vector 2933 Message Digest 2934 Assigned Cookie 2935 L2-Specific Sublayer 2936 Data Sequencing 2937 Tx Connect Speed 2938 Rx Connect Speed 2939 Physical Channel ID 2941 6.8. Incoming-Call-Connected (ICCN) 2943 Incoming-Call-Connected (ICCN) is the control message sent by the 2944 LCCE that originally sent an ICRQ upon receiving an ICRP from its 2945 peer. It is the final message in the three-message exchange used for 2946 establishing L2TP sessions. 2948 The ICCN is used to indicate that the ICRP was accepted, that the 2949 call has been established, and that the L2TP session should move to 2950 the established state. It also allows the sender to indicate 2951 specific parameters about the established call (parameters that may 2952 not have been available at the time the ICRQ was issued). 2954 The following AVPs MUST be present in the ICCN: 2956 Message Type 2957 Local Session ID 2958 Remote Session ID 2960 The following AVPs MAY be present in the ICCN: 2962 Random Vector 2963 Message Digest 2964 L2-Specific Sublayer 2965 Data Sequencing 2966 Tx Connect Speed 2967 Rx Connect Speed 2968 Circuit Status 2970 6.9. Outgoing-Call-Request (OCRQ) 2972 Outgoing-Call-Request (OCRQ) is the control message sent by an LCCE 2973 to an LAC to indicate that an outbound call at the LAC is to be 2974 established based on specific destination information sent in this 2975 message. It is the first in a three-message exchange used for 2976 establishing a session and placing a call on behalf of the initiating 2977 LCCE. 2979 Note that a call may be any L2 connection requiring well-known 2980 destination information to be sent from an LCCE to an LAC. This call 2981 could be a dialup connection to the PSTN, an SVC connection, the IP 2982 address of another LCCE, or any other destination dictated by the 2983 sender of this message. 2985 The following AVPs MUST be present in the OCRQ: 2987 Message Type 2988 Local Session ID 2989 Remote Session ID 2990 Serial Number 2991 Pseudowire Type 2992 Remote End ID 2993 Circuit Status 2995 The following AVPs MAY be present in the OCRQ: 2997 Random Vector 2998 Message Digest 2999 Assigned Cookie 3000 Tx Connect Speed 3001 Rx Connect Speed 3002 Session Tie Breaker 3003 L2-Specific Sublayer 3004 Data Sequencing 3006 6.10. Outgoing-Call-Reply (OCRP) 3008 Outgoing-Call-Reply (OCRP) is the control message sent by an LAC to 3009 an LCCE in response to a received OCRQ. It is the second in a 3010 three-message exchange used for establishing a session within an L2TP 3011 control connection. 3013 OCRP is used to indicate that the LAC has been able to attempt the 3014 outbound call. The message returns any relevant parameters regarding 3015 the call attempt. Data MUST NOT be forwarded until the OCCN is 3016 received, which indicates that the call has been placed. 3018 The following AVPs MUST be present in the OCRP: 3020 Message Type 3021 Local Session ID 3022 Remote Session ID 3023 Circuit Status 3025 The following AVPs MAY be present in the OCRP: 3027 Random Vector 3028 Message Digest 3029 Assigned Cookie 3030 L2-Specific Sublayer 3031 Tx Connect Speed 3032 Rx Connect Speed 3033 Data Sequencing 3034 Physical Channel ID 3036 6.11. Outgoing-Call-Connected (OCCN) 3038 Outgoing-Call-Connected (OCCN) is the control message sent by an LAC 3039 to another LCCE after the OCRP and after the outgoing call has been 3040 completed. It is the final message in a three-message exchange used 3041 for establishing a session. 3043 OCCN is used to indicate that the result of a requested outgoing call 3044 was successful. It also provides information to the LCCE who 3045 requested the call about the particular parameters obtained after the 3046 call was established. 3048 The following AVPs MUST be present in the OCCN: 3050 Message Type 3051 Local Session ID 3052 Remote Session ID 3054 The following AVPs MAY be present in the OCCN: 3056 Random Vector 3057 Message Digest 3058 L2-Specific Sublayer 3059 Tx Connect Speed 3060 Rx Connect Speed 3061 Data Sequencing 3062 Circuit Status 3064 6.12. Call-Disconnect-Notify (CDN) 3066 The Call-Disconnect-Notify (CDN) is a control message sent by an LCCE 3067 to request disconnection of a specific session. Its purpose is to 3068 inform the peer of the disconnection and the reason for the 3069 disconnection. The peer MUST clean up any resources, and does not 3070 send back any indication of success or failure for such cleanup. 3072 The following AVPs MUST be present in the CDN: 3074 Message Type 3075 Result Code 3076 Local Session ID 3077 Remote Session ID 3079 The following AVP MAY be present in the CDN: 3081 Random Vector 3082 Message Digest 3084 6.13. WAN-Error-Notify (WEN) 3086 The WAN-Error-Notify (WEN) is a control message sent from an LAC to 3087 an LNS to indicate WAN error conditions. The counters in this 3088 message are cumulative. This message should only be sent when an 3089 error occurs, and not more than once every 60 seconds. The counters 3090 are reset when a new call is established. 3092 The following AVPs MUST be present in the WEN: 3094 Message Type 3095 Local Session ID 3096 Remote Session ID 3097 Circuit Errors 3099 The following AVP MAY be present in the WEN: 3101 Random Vector 3102 Message Digest 3104 6.14. Set-Link-Info (SLI) 3106 The Set-Link-Info control message is sent by an LCCE to convey link 3107 or circuit status change information regarding the circuit associated 3108 with this L2TP session. For example, if PPP renegotiates LCP at an 3109 LNS or between an LAC and a Remote System, or if a forwarded Frame 3110 Relay VC transitions to Active or Inactive at an LAC, an SLI message 3111 SHOULD be sent to indicate this event. Precise details of when the 3112 SLI is sent, what PW type-specific AVPs must be present, and how 3113 those AVPs should be interpreted by the receiving peer are outside 3114 the scope of this document. These details should be described in the 3115 associated pseudowire-specific documents that require use of this 3116 message. 3118 The following AVPs MUST be present in the SLI: 3120 Message Type 3121 Local Session ID 3122 Remote Session ID 3124 The following AVPs MAY be present in the SLI: 3126 Random Vector 3127 Message Digest 3128 Circuit Status 3130 6.15. Explicit-Acknowledgement (ACK) 3132 The Explicit Acknowledgement (ACK) message is used only to 3133 acknowledge receipt of a message or messages on the control 3134 connection (e.g., for purposes of updating Ns and Nr values). 3135 Receipt of this message does not trigger an event for the L2TP 3136 protocol state machine. 3138 A message received without any AVPs (including the Message Type AVP), 3139 is referred to as a Zero Length Body (ZLB) message, and serves the 3140 same function as the Explicit Acknowledgement. ZLB messages are only 3141 permitted when Control Message Authentication defined in Section 4.3 3142 is not enabled. 3144 The following AVPs MAY be present in the ACK message: 3146 Message Type 3147 Message Digest 3149 7. Control Connection State Machines 3151 The state tables defined in this section govern the exchange of 3152 control messages defined in Section 6. Tables are defined for 3153 incoming call placement and outgoing call placement, as well as for 3154 initiation of the control connection itself. The state tables do not 3155 encode timeout and retransmission behavior, as this is handled in the 3156 underlying reliable control message delivery mechanism (see Section 3157 4.2). 3159 7.1. Malformed AVPs and Control Messages 3161 Receipt of an invalid or unrecoverable malformed control message 3162 SHOULD be logged appropriately and the control connection cleared to 3163 ensure recovery to a known state. The control connection may then be 3164 restarted by the initiator. 3166 An invalid control message is defined as (1) a message that contains 3167 a Message Type marked as mandatory (see Section 5.4.1) but that is 3168 unknown to the implementation, or (2) a control message that is 3169 received in the wrong state. 3171 Examples of malformed control messages include (1) a message that has 3172 an invalid value in its header, (2) a message that contains an AVP 3173 that is formatted incorrectly or whose value is out of range, and (3) 3174 a message that is missing a required AVP. A control message with a 3175 malformed header MUST be discarded. 3177 When possible, a malformed AVP should be treated as an unrecognized 3178 AVP (see Section 5.2). Thus, an attempt to inspect the M bit SHOULD 3179 be made to determine the importance of the malformed AVP, and thus, 3180 the severity of the malformation to the entire control message. If 3181 the M bit can be reasonably inspected within the malformed AVP and is 3182 determined to be set, then as with an unrecognized AVP, the 3183 associated session or control connection MUST be shut down. If the M 3184 bit is inspected and is found to be 0, the AVP MUST be ignored 3185 (assuming recovery from the AVP malformation is indeed possible). 3187 This policy must not be considered as a license to send malformed 3188 AVPs, but rather, as a guide towards how to handle an improperly 3189 formatted message if one is received. It is impossible to list all 3190 potential malformations of a given message and give advice for each. 3191 One example of a malformed AVP situation that should be recoverable 3192 is if the Rx Connect Speed AVP is received with a length of 10 rather 3193 than 14, implying that the connect speed bits-per-second is being 3194 formatted in 4 octets rather than 8. If the AVP does not have its M 3195 bit set (as would typically be the case), this condition is not 3196 considered catastrophic. As such, the control message should be 3197 accepted as though the AVP were not present (though a local error 3198 message may be logged). 3200 In several cases in the following tables, a protocol message is sent, 3201 and then a "clean up" occurs. Note that, regardless of the initiator 3202 of the control connection destruction, the reliable delivery 3203 mechanism must be allowed to run (see Section 4.2) before destroying 3204 the control connection. This permits the control connection 3205 management messages to be reliably delivered to the peer. 3207 Appendix B.1 contains an example of lock-step control connection 3208 establishment. 3210 7.2. Control Connection States 3212 The L2TP control connection protocol is not distinguishable between 3213 the two LCCEs but is distinguishable between the originator and 3214 receiver. The originating peer is the one that first initiates 3215 establishment of the control connection. (In a tie breaker 3216 situation, this is the winner of the tie.) Since either the LAC or 3217 the LNS can be the originator, a collision can occur. See the 3218 Control Connection Tie Breaker AVP in Section 5.4.3 for a description 3219 of this and its resolution. 3221 State Event Action New State 3222 ----- ----- ------ --------- 3223 idle Local open Send SCCRQ wait-ctl-reply 3224 request 3226 idle Receive SCCRQ, Send SCCRP wait-ctl-conn 3227 acceptable 3229 idle Receive SCCRQ, Send StopCCN, idle 3230 not acceptable clean up 3232 idle Receive SCCRP Send StopCCN, idle 3233 clean up 3235 idle Receive SCCCN Send StopCCN, idle 3236 clean up 3237 wait-ctl-reply Receive SCCRP, Send SCCCN, established 3238 acceptable send control-conn 3239 open event to 3240 waiting sessions 3242 wait-ctl-reply Receive SCCRP, Send StopCCN, idle 3243 not acceptable clean up 3245 wait-ctl-reply Receive SCCRQ, Send SCCRP, wait-ctl-conn 3246 lose tie breaker, Clean up losing 3247 SCCRQ acceptable connection 3249 wait-ctl-reply Receive SCCRQ, Send StopCCN, idle 3250 lose tie breaker, Clean up losing 3251 SCCRQ unacceptable connection 3253 wait-ctl-reply Receive SCCRQ, Send StopCCN for wait-ctl-reply 3254 win tie breaker losing connection 3256 wait-ctl-reply Receive SCCCN Send StopCCN, idle 3257 clean up 3259 wait-ctl-conn Receive SCCCN, Send control-conn established 3260 acceptable open event to 3261 waiting sessions 3263 wait-ctl-conn Receive SCCCN, Send StopCCN, idle 3264 not acceptable clean up 3266 wait-ctl-conn Receive SCCRQ, Send StopCCN, idle 3267 SCCRP clean up 3269 established Local open Send control-conn established 3270 request open event to 3271 (new call) waiting sessions 3273 established Administrative Send StopCCN, idle 3274 control-conn clean up 3275 close event 3277 established Receive SCCRQ, Send StopCCN, idle 3278 SCCRP, SCCCN clean up 3280 idle, Receive StopCCN Clean up idle 3281 wait-ctl-reply, 3282 wait-ctl-conn, 3283 established 3285 The states associated with an LCCE for control connection 3286 establishment are as follows: 3288 idle 3289 Both initiator and recipient start from this state. An initiator 3290 transmits an SCCRQ, while a recipient remains in the idle state 3291 until receiving an SCCRQ. 3293 wait-ctl-reply 3294 The originator checks to see if another connection has been 3295 requested from the same peer, and if so, handles the collision 3296 situation described in Section 5.4.3. 3298 wait-ctl-conn 3299 Awaiting an SCCCN. If the SCCCN is valid, the control connection 3300 is established; otherwise, it is torn down (sending a StopCCN with 3301 the proper result and/or error code). 3303 established 3304 An established connection may be terminated by either a local 3305 condition or the receipt of a StopCCN. In the event of a local 3306 termination, the originator MUST send a StopCCN and clean up the 3307 control connection. If the originator receives a StopCCN, it MUST 3308 also clean up the control connection. 3310 7.3. Incoming Calls 3312 An ICRQ is generated by an LCCE, typically in response to an incoming 3313 call or a local event. Once the LCCE sends the ICRQ, it waits for a 3314 response from the peer. However, it may choose to postpone 3315 establishment of the call (e.g., answering the call, bringing up the 3316 circuit) until the peer has indicated with an ICRP that it will 3317 accept the call. The peer may choose not to accept the call if, for 3318 instance, there are insufficient resources to handle an additional 3319 session. 3321 If the peer chooses to accept the call, it responds with an ICRP. 3322 When the local LCCE receives the ICRP, it attempts to establish the 3323 call. A final call connected message, the ICCN, is sent from the 3324 local LCCE to the peer to indicate that the call states for both 3325 LCCEs should enter the established state. If the call is terminated 3326 before the peer can accept it, a CDN is sent by the local LCCE to 3327 indicate this condition. 3329 When a call transitions to a "disconnected" or "down" state, the call 3330 is cleared normally, and the local LCCE sends a CDN. Similarly, if 3331 the peer wishes to clear a call, it sends a CDN and cleans up its 3332 session. 3334 7.3.1. ICRQ Sender States 3336 State Event Action New State 3337 ----- ----- ------ --------- 3339 idle Call signal or Initiate local wait-control-conn 3340 ready to receive control-conn 3341 incoming conn open 3343 idle Receive ICCN, Clean up idle 3344 ICRP, CDN 3346 wait-control- Bearer line drop Clean up idle 3347 conn or local close 3348 request 3350 wait-control- control-conn-open Send ICRQ wait-reply 3351 conn 3353 wait-reply Receive ICRP, Send ICCN established 3354 acceptable 3356 wait-reply Receive ICRP, Send CDN, idle 3357 Not acceptable 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 3375 established Receive ICRQ, Send CDN, idle 3376 ICRP, ICCN clean up 3378 established Local close Send CDN, idle 3379 request clean up 3381 The states associated with the ICRQ sender are as follows: 3383 idle 3384 The LCCE detects an incoming call on one of its interfaces (e.g., 3385 an analog PSTN line rings, or an ATM PVC is provisioned), or a 3386 local event occurs. The LCCE initiates its control connection 3387 establishment state machine and moves to a state waiting for 3388 confirmation of the existence of a control connection. 3390 wait-control-conn 3391 In this state, the session is waiting for either the control 3392 connection to be opened or for verification that the control 3393 connection is already open. Once an indication that the control 3394 connection has been opened is received, session control messages 3395 may be exchanged. The first of these messages is the ICRQ. 3397 wait-reply 3398 The ICRQ sender receives either (1) a CDN indicating the peer is 3399 not willing to accept the call (general error or do not accept) 3400 and moves back into the idle state, or (2) an ICRP indicating the 3401 call is accepted. In the latter case, the LCCE sends an ICCN and 3402 enters the established state. 3404 established 3405 Data is exchanged over the session. The call may be cleared by 3406 any of the following: 3407 + An event on the connected interface: The LCCE sends a CDN. 3408 + Receipt of a CDN: The LCCE cleans up, disconnecting the call. 3409 + A local reason: The LCCE sends a CDN. 3411 7.3.2. ICRQ Recipient States 3413 State Event Action New State 3414 ----- ----- ------ --------- 3415 idle Receive ICRQ, Send ICRP wait-connect 3416 acceptable 3418 idle Receive ICRQ, Send CDN, idle 3419 not acceptable clean up 3421 idle Receive ICRP Send CDN idle 3422 clean up 3424 idle Receive ICCN Clean up idle 3426 wait-connect Receive ICCN, Prepare for established 3427 acceptable data 3429 wait-connect Receive ICCN, Send CDN, idle 3430 not acceptable clean up 3432 wait-connect Receive ICRQ, Send CDN, idle 3433 ICRP clean up 3435 idle, Receive CDN Clean up idle 3436 wait-connect, 3437 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 3484 wait-reply Receive OCRP, none wait-connect 3485 acceptable 3487 wait-reply Receive OCRP, Send CDN, idle 3488 not acceptable clean up 3490 wait-reply Receive OCCN Send CDN, idle 3491 clean up 3493 wait-reply Receive OCRQ, Process as idle 3494 lose tie breaker OCRQ Recipient 3495 (Section 7.4.2) 3497 wait-reply Receive OCRQ, Send CDN wait-reply 3498 win tie breaker for losing 3499 session 3501 wait-connect Receive OCCN none established 3503 wait-connect Receive OCRQ, Send CDN, idle 3504 OCRP clean up 3506 idle, Receive CDN Clean up idle 3507 wait-reply, 3508 wait-connect, 3509 established 3511 established Receive OCRQ, Send CDN, idle 3512 OCRP, OCCN clean up 3514 wait-reply, Local close Send CDN, idle 3515 wait-connect, request clean up 3516 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 3575 wait-cs-answer, Local close Send CDN, idle 3576 established request clean up 3578 The states associated with the LAC for outgoing calls are as follows: 3580 idle 3581 If the OCRQ is received in error, respond with a CDN. Otherwise, 3582 place the call, send an OCRP, and move to the wait-cs-answer 3583 state. 3585 wait-cs-answer 3586 If the call is not completed or a timer expires while waiting for 3587 the call to complete, send a CDN with the appropriate error 3588 condition set, and go to idle state. If a circuit-switched 3589 connection is established, send an OCCN indicating success, and go 3590 to established state. 3592 established 3593 If the LAC receives a CDN from the peer, the call MUST be released 3594 via appropriate mechanisms, and the session cleaned up. If the 3595 call is disconnected because the circuit transitions to a 3596 "disconnected" or "down" state, the LAC MUST send a CDN to the 3597 peer and return to idle state. 3599 7.5. Termination of a Control Connection 3601 The termination of a control connection consists of either peer 3602 issuing a StopCCN. The sender of this message SHOULD wait a full 3603 control message retransmission cycle (e.g., 1 + 2 + 4 + 8 ... 3604 seconds) for the acknowledgment of this message before releasing the 3605 control information associated with the control connection. The 3606 recipient of this message should send an acknowledgment of the 3607 message to the peer, then release the associated control information. 3609 When to release a control connection is an implementation issue and 3610 is not specified in this document. A particular implementation may 3611 use whatever policy is appropriate for determining when to release a 3612 control connection. Some implementations may leave a control 3613 connection open for a period of time or perhaps indefinitely after 3614 the last session for that control connection is cleared. Others may 3615 choose to disconnect the control connection immediately after the 3616 last call on the control connection disconnects. 3618 8. Security Considerations 3620 This section addresses some of the security issues that L2TP 3621 encounters in its operation. 3623 8.1. Control Connection Endpoint and Message Security 3625 If a shared secret (password) exists between two LCCEs, it may be 3626 used to perform a mutual authentication between the two LCCEs, and 3627 construct an authentication and integrity check of arriving L2TP 3628 control messages. The mechanism provided by L2TPv3 is described in 3629 Section 4.3 and in the definition of the Message Digest and Control 3630 Message Authentication Nonce AVPs in Section 5.4.1. 3632 This control message security mechanism provides for (1) mutual 3633 endpoint authentication, and (2) individual control message integrity 3634 and authenticity checking. Mutual endpoint authentication ensures 3635 that an L2TPv3 control connection is only established between two 3636 endpoints that are configured with the proper password. The 3637 individual control message and integrity check guards against 3638 accidental or intentional packet corruption (i.e., those caused by a 3639 control message spoofing or man-in-the-middle attack). 3641 The shared secret that is used for all control connection, control 3642 message, and AVP security features defined in this document never 3643 needs to be sent in the clear between L2TP tunnel endpoints. 3645 8.2. Data Packet Spoofing 3647 Packet spoofing for any type of Virtual Private Network (VPN) 3648 protocol is of particular concern as insertion of carefully 3649 constructed rogue packets into the VPN transit network could result 3650 in a violation of VPN traffic separation, leaking data into a 3651 customer VPN. This is complicated by the fact that it may be 3652 particularly difficult for the operator of the VPN to even be aware 3653 that it has become a point of transit into or between customer VPNs. 3655 L2TPv3 provides traffic separation for its VPNs via a 32-bit Session 3656 ID in the L2TPv3 data header. When present, the L2TPv3 Cookie 3657 (described in Section 4.1), provides an additional check to ensure 3658 that an arriving packet is intended for the identified session. 3659 Thus, use of a Cookie with the Session ID provides an extra guarantee 3660 that the Session ID lookup was performed properly and that the 3661 Session ID itself was not corrupted in transit. 3663 In the presence of a blind packet spoofing attack, the Cookie may 3664 also provide security against inadvertent leaking of frames into a 3665 customer VPN. To illustrate the type of security that it is provided 3666 in this case, consider comparing the validation of a 64-bit Cookie in 3667 the L2TPv3 header to the admission of packets that match a given 3668 source and destination IP address pair. Both the source and 3669 destination IP address pair validation and Cookie validation consist 3670 of a fast check on cleartext header information on all arriving 3671 packets. However, since L2TPv3 uses its own value, it removes the 3672 requirement for one to maintain a list of (potentially several) 3673 permitted or denied IP addresses, and moreover, to guard knowledge of 3674 the permitted IP addresses from hackers who may obtain and spoof 3675 them. Further, it is far easier to change a compromised L2TPv3 3676 Cookie than a compromised IP address," and a cryptographically random 3677 [RFC1750] value is far less likely to be discovered by brute-force 3678 attacks compared to an IP address. 3680 For protection against brute-force, blind, insertion attacks, a 64- 3681 bit Cookie MUST be used with all sessions. A 32-bit Cookie is 3682 vulnerable to brute-force guessing at high packet rates, and as such, 3683 should not be considered an effective barrier to blind insertion 3684 attacks (though it is still useful as an additional verification of a 3685 successful Session ID lookup). The Cookie provides no protection 3686 against a sophisticated man-in-the-middle attacker who can sniff and 3687 correlate captured data between nodes for use in a coordinated 3688 attack. 3690 The Assigned Cookie AVP is used to signal the value and size of the 3691 Cookie that must be present in all data packets for a given session. 3692 Each Assigned Cookie MUST be selected in a cryptographically random 3693 manner [RFC1750] such that a series of Assigned Cookies does not 3694 provide any indication of what a future Cookie will be. 3696 The L2TPv3 Cookie must not be regarded as a substitute for security 3697 such as that provided by IPsec when operating over an open or 3698 untrusted network where packets may be sniffed, decoded, and 3699 correlated for use in a coordinated attack. See Section 4.1.3 for 3700 more information on running L2TP over IPsec. 3702 9. Internationalization Considerations 3704 The Host Name and Vendor Name AVPs are not internationalized. The 3705 Vendor Name AVP, although intended to be human-readable, would seem 3706 to fit in the category of "globally visible names" [RFC2277] and so 3707 is represented in US-ASCII. 3709 If (1) an LCCE does not signify a language preference by the 3710 inclusion of a Preferred Language AVP (see Section 5.4.3) in the 3711 SCCRQ or SCCRP, (2) the Preferred Language AVP is unrecognized, or 3712 (3) the requested language is not supported by the peer LCCE, the 3713 default language [RFC2277] MUST be used for all internationalized 3714 strings sent by the peer. 3716 10. IANA Considerations 3718 This document defines a number of "magic" numbers to be maintained by 3719 the IANA. This section explains the criteria used by the IANA to 3720 assign additional numbers in each of these lists. The following 3721 subsections describe the assignment policy for the namespaces defined 3722 elsewhere in this document. 3724 Sections 10.1 through 10.3 are requests for new values already 3725 managed by IANA according to [RFC3438]. 3727 The remaining sections are for new registries that have been added to 3728 the existing L2TP registry and are maintained by IANA accordingly. 3730 10.1. Control Message Attribute Value Pairs (AVPs) 3732 This number space is managed by IANA as per [RFC3438]. 3734 A summary of the new AVPs follows: 3736 Control Message Attribute Value Pairs 3738 Attribute 3739 Type Description 3740 --------- ------------------ 3742 58 Extended Vendor ID AVP 3743 59 Message Digest 3744 60 Router ID 3745 61 Assigned Control Connection ID 3746 62 Pseudowire Capabilities List 3747 63 Local Session ID 3748 64 Remote Session ID 3749 65 Assigned Cookie 3750 66 Remote End ID 3751 68 Pseudowire Type 3752 69 L2-Specific Sublayer 3753 70 Data Sequencing 3754 71 Circuit Status 3755 72 Preferred Language 3756 73 Control Message Authentication Nonce 3757 74 Tx Connect Speed 3758 75 Rx Connect Speed 3760 10.2. Message Type AVP Values 3762 This number space is managed by IANA as per [RFC3438]. There is one 3763 new message type, defined in Section 3.1, that was allocated for this 3764 specification: 3766 Message Type AVP (Attribute Type 0) Values 3767 ------------------------------------------ 3769 Control Connection Management 3771 20 (ACK) Explicit Acknowledgement 3773 10.3. Result Code AVP Values 3775 This number space is managed by IANA as per [RFC3438]. 3777 New Result Code values for the CDN message are defined in Section 3778 5.4. The following is a summary: 3780 Result Code AVP (Attribute Type 1) Values 3781 ----------------------------------------- 3783 General Error Codes 3785 13 - Session not established due to losing 3786 tie breaker (L2TPv3). 3787 14 - Session not established due to unsupported 3788 PW type (L2TPv3). 3789 15 - Session not established, sequencing required 3790 without valid L2-Specific Sublayer (L2TPv3). 3791 16 - Finite state machine error or timeout. 3793 10.4. AVP Header Bits 3795 This is a new registry for IANA to maintain. 3797 Leading Bits of the L2TP AVP Header 3798 ----------------------------------- 3800 There six bits at the beginning of the L2TP AVP header. New bits are 3801 assigned via Standards Action [RFC2434]. 3803 Bit 0 - Mandatory (M bit) 3804 Bit 1 - Hidden (H bit) 3805 Bit 2 - Reserved 3806 Bit 3 - Reserved 3807 Bit 4 - Reserved 3808 Bit 5 - Reserved 3810 10.5. L2TP Control Message Header Bits 3812 This is a new registry for IANA to maintain. 3814 Leading Bits of the L2TP Control Message Header 3815 ----------------------------------------------- 3817 There are 12 bits at the beginning of the L2TP Control Message 3818 Header. Reserved bits should only be defined by Standard 3819 Action [RFC2434]. 3821 Bit 0 - Message Type (T bit) 3822 Bit 1 - Length Field is Present (L bit) 3823 Bit 2 - Reserved 3824 Bit 3 - Reserved 3825 Bit 4 - Sequence Numbers Present (S bit) 3826 Bit 5 - Reserved 3827 Bit 6 - Offset Field is Present [RFC2661] 3828 Bit 7 - Priority Bit (P bit) [RFC2661] 3829 Bit 8 - Reserved 3830 Bit 9 - Reserved 3831 Bit 10 - Reserved 3832 Bit 11 - Reserved 3834 10.6. Pseudowire Types 3836 This is a new registry for IANA to maintain, there are no values 3837 assigned within this document to maintain. 3839 L2TPv3 Pseudowire Types 3840 ----------------------- 3842 The Pseudowire Type (PW Type, see Section 5.4) is a 2-octet value 3843 used in the Pseudowire Type AVP and Pseudowire Capabilities List AVP 3844 defined in Section 5.4.3. 0 to 32767 are assignable by Expert Review 3845 [RFC2434], while 32768 to 65535 are assigned by a First Come First 3846 Served policy [RFC2434]. There are no specific pseudowire types 3847 assigned within this document. Each pseudowire-specific document 3848 must allocate its own PW types from IANA as necessary. 3850 10.7. Circuit Status Bits 3852 This is a new registry for IANA to maintain. 3854 Circuit Status Bits 3855 ------------------- 3857 The Circuit Status field is a 16-bit mask, with the two low order 3858 bits assigned. Additional bits may be assigned by IETF Consensus 3859 [RFC2434]. 3861 Bit 14 - New (N bit) 3862 Bit 15 - Active (A bit) 3864 10.8. Default L2-Specific Sublayer bits 3866 This is a new registry for IANA to maintain. 3868 Default L2-Specific Sublayer Bits 3869 --------------------------------- 3871 The Default L2-Specific Sublayer contains 8 bits in the low-order 3872 portion of the header. Reserved bits may be assigned by IETF 3873 Consensus [RFC2434]. 3875 Bit 0 - Reserved 3876 Bit 1 - Sequence (S bit) 3877 Bit 2 - Reserved 3878 Bit 3 - Reserved 3879 Bit 4 - Reserved 3880 Bit 5 - Reserved 3881 Bit 6 - Reserved 3882 Bit 7 - Reserved 3884 10.9. L2-Specific Sublayer Type 3886 This is a new registry for IANA to maintain. 3888 L2-Specific Sublayer Type 3889 ------------------------- 3891 The L2-Specific Sublayer Type is a 2-octet unsigned integer. 3892 Additional values may be assigned by Expert Review [RFC2434]. 3894 0 - No L2-Specific Sublayer 3895 1 - Default L2-Specific Sublayer present 3897 10.10. Data Sequencing Level 3899 This is a new registry for IANA to maintain. 3901 Data Sequencing Level 3902 --------------------- 3904 The Data Sequencing Level is a 2-octet unsigned integer 3905 Additional values may be assigned by Expert Review [RFC2434]. 3907 0 - No incoming data packets require sequencing. 3908 1 - Only non-IP data packets require sequencing. 3909 2 - All incoming data packets require sequencing. 3911 11. References 3913 11.1. Normative References 3915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3916 Requirement Levels", BCP 14, RFC 2119, March 1997. 3918 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 3919 Languages", BCP 18, RFC 2277, January 1998. 3921 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3922 IANA Considerations section in RFCs", BCP 26, RFC 2434, 3923 October 1998. 3925 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 3926 Specification", RFC 2473, December 1998. 3928 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., 3929 and Palter, B., "Layer Two Tunneling Layer Two Tunneling 3930 Protocol (L2TP)", RFC 2661, August 1999. 3932 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 3933 "Remote Authentication Dial In User Service (RADIUS)", RFC 3934 2865, June 2000. 3936 [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", 3937 BCP 47, RFC 3066, January 2001. 3939 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and Booth, S., 3940 "Securing L2TP using IPsec", RFC 3193, November 2001. 3942 [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet 3943 Assigned Numbers Authority (IANA) Considerations Update", 3944 BCP 68, RFC 3438, December 2002. 3946 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 3947 STD 63, RFC 3629, November 2003. 3949 11.2. Informative References 3951 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 3952 STD 13, RFC 1034, November 1987. 3954 [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 3955 November 1990. 3957 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 3958 April 1992. 3960 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 3961 51, RFC 1661, July 1994. 3963 [RFC1700] Reynolds, J. and Postel, J., "Assigned Numbers", STD 2, RFC 3964 1700, October 1994. 3966 [RFC1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness 3967 Recommendations for Security", RFC 1750, December 1994. 3969 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 3970 Internet", RFC 1958, June 1996. 3972 [RFC1981] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery 3973 for IP version 6", RFC 1981, August 1996. 3975 [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, 3976 January 1997. 3978 [RFC2104] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC: Keyed- 3979 Hashing for Message Authentication", RFC 2104, February 3980 1997. 3982 [RFC2341] Valencia, A., Littlewood, M., and Kolar, T., "Cisco Layer 3983 Two Forwarding (Protocol) L2F", RFC 2341, May 1998. 3985 [RFC2401] Kent, S. and Atkinson, R., "Security Architecture for the 3986 Internet Protocol", RFC 2401, November 1998. 3988 [RFC2581] Allman, M., Paxson, V. and Stevens, W., "TCP Congestion 3989 Control", RFC 2581, April 1999. 3991 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., 3992 and Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", 3993 RFC 2637, July 1999. 3995 [RFC2732] Hinden, R., Carpenter, B., and Masinter, L., "Format for 3996 Literal IPv6 Addresses in URL's", RFC 2732, December 1999. 3998 [RFC2809] Aboba, B. and Zorn, G., "Implementation of L2TP Compulsory 3999 Tunneling via RADIUS", RFC 2809, April 2000. 4001 [RFC3070] Rawat, V., Tio, R., Nanji, S., and Verma, R., "Layer Two 4002 Tunneling Protocol (L2TP) over Frame Relay", RFC 3070, 4003 February 2001. 4005 [RFC3355] Singh, A., Turner, R., Tio, R., and Nanji, S., "Layer Two 4006 Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 4007 (AAL5)", RFC 3355, August 2002. 4009 [KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network 4010 Security: Private Communications in a Public World", 4011 Prentice Hall, March 1995, ISBN 0-13-061466-1. 4013 [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I: The 4014 Protocols", Addison-Wesley Publishing Company, Inc., March 4015 1996, ISBN 0-201-63346-9. 4017 12. Acknowledgments 4019 Many of the protocol constructs were originally defined in, and the 4020 text of this document began with, RFC 2661, "L2TPv2". RFC 2661 4021 authors are W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn and 4022 B. Palter. 4024 The basic concept for L2TP and many of its protocol constructs were 4025 adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these 4026 versions are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. 4027 Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn. 4029 Danny Mcpherson and Suhail Nanji published the first "L2TP Service 4030 Type" version, which defined the use of L2TP for tunneling of various 4031 L2 payload types (initially, Ethernet and Frame Relay). 4033 The team for splitting RFC 2661 into this base document and the 4034 companion PPP document consisted of Ignacio Goyret, Jed Lau, Bill 4035 Palter, Mark Townsley, and Madhvi Verma. Skip Booth also provided 4036 very helpful review and comment. 4038 Some constructs of L2TPv3 were based in part on UTI (Universal 4039 Transport Interface), which was originally conceived by Peter 4040 Lothberg and Tony Bates. 4042 Stewart Bryant and Simon Barber provided valuable input for the 4043 L2TPv3 over IP header. 4045 Juha Heinanen provided helpful review in the early stages of this 4046 effort. 4048 Jan Vilhuber, Scott Fluhrer, David McGrew, Scott Wainner, Skip Booth 4049 and Maria Dos Santos contributed to the Control Message 4050 Authentication Mechanism as well as general discussions of security. 4052 James Carlson, Thomas Narten, Maria Dos Santos, Steven Bellovin, Ted 4053 Hardie and Pekka Savola provided very helpful review of the final 4054 versions of text. 4056 Russ Housley provided valuable review and comment on security, 4057 particularly with respect to the Control Message Authentication 4058 mechanism. 4060 Pekka Savola contributed to proper alignment with IPv6 and inspired 4061 much of Section 4.1.4 on fragmentation. 4063 Aside of his original influence and co-authorship of RFC 2661, Glen 4064 Zorn helped get all of the language and character references straight 4065 in this document. 4067 A number of people provided valuable input and effort for RFC 2661, 4068 on which this document was based: 4070 John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, 4071 Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and 4072 review at the 43rd IETF in Orlando, FL, which led to improvement of 4073 the overall readability and clarity of RFC 2661. 4075 Thomas Narten provided a great deal of critical review and 4076 formatting. He wrote the first version of the IANA Considerations 4077 section. 4079 Dory Leifer made valuable refinements to the protocol definition of 4080 L2TP and contributed to the editing of early versions leading to RFC 4081 2661. 4083 Steve Cobb and Evan Caves redesigned the state machine tables. 4084 Barney Wolff provided a great deal of design input on the original 4085 endpoint authentication mechanism. 4087 Appendix A: Control Slow Start and Congestion Avoidance 4089 Although each side has indicated the maximum size of its receive 4090 window, it is recommended that a slow start and congestion avoidance 4091 method be used to transmit control packets. The methods described 4092 here are based upon the TCP congestion avoidance algorithm as 4093 described in Section 21.6 of TCP/IP Illustrated, Volume I, by W. 4094 Richard Stevens [STEVENS] (this algorithm is also described in 4095 [RFC2581]). 4097 Slow start and congestion avoidance make use of several variables. 4098 The congestion window (CWND) defines the number of packets a sender 4099 may send before waiting for an acknowledgment. The size of CWND 4100 expands and contracts as described below. Note, however, that CWND 4101 is never allowed to exceed the size of the advertised window obtained 4102 from the Receive Window AVP. (In the text below, it is assumed any 4103 increase will be limited by the Receive Window Size.) The variable 4104 SSTHRESH determines when the sender switches from slow start to 4105 congestion avoidance. Slow start is used while CWND is less than 4106 SSHTRESH. 4108 A sender starts out in the slow start phase. CWND is initialized to 4109 one packet, and SSHTRESH is initialized to the advertised window 4110 (obtained from the Receive Window AVP). The sender then transmits 4111 one packet and waits for its acknowledgment (either explicit or 4112 piggybacked). When the acknowledgment is received, the congestion 4113 window is incremented from one to two. During slow start, CWND is 4114 increased by one packet each time an ACK (explicit ACK message or 4115 piggybacked) is received. Increasing CWND by one on each ACK has the 4116 effect of doubling CWND with each round trip, resulting in an 4117 exponential increase. When the value of CWND reaches SSHTRESH, the 4118 slow start phase ends and the congestion avoidance phase begins. 4120 During congestion avoidance, CWND expands more slowly. Specifically, 4121 it increases by 1/CWND for every new ACK received. That is, CWND is 4122 increased by one packet after CWND new ACKs have been received. 4123 Window expansion during the congestion avoidance phase is effectively 4124 linear, with CWND increasing by one packet each round trip. 4126 When congestion occurs (indicated by the triggering of a 4127 retransmission) one-half of the CWND is saved in SSTHRESH, and CWND 4128 is set to one. The sender then reenters the slow start phase. 4130 Appendix B: Control Message Examples 4132 B.1: Lock-Step Control Connection Establishment 4134 In this example, an LCCE establishes a control connection, with the 4135 exchange involving each side alternating in sending messages. This 4136 example shows the final acknowledgment explicitly sent within an ACK 4137 message. An alternative would be to piggyback the acknowledgment 4138 within a message sent as a reply to the ICRQ or OCRQ that will likely 4139 follow from the side that initiated the control connection. 4141 LCCE A LCCE B 4142 ------ ------ 4143 SCCRQ -> 4144 Nr: 0, Ns: 0 4145 <- SCCRP 4146 Nr: 1, Ns: 0 4147 SCCCN -> 4148 Nr: 1, Ns: 1 4149 <- ACK 4150 Nr: 2, Ns: 1 4152 B.2: Lost Packet with Retransmission 4154 An existing control connection has a new session requested by LCCE A. 4155 The ICRP is lost and must be retransmitted by LCCE B. Note that loss 4156 of the ICRP has two effects: It not only keeps the upper level state 4157 machine from progressing, but also keeps LCCE A from seeing a timely 4158 lower level acknowledgment of its ICRQ. 4160 LCCE A LCCE B 4161 ------ ------ 4162 ICRQ -> 4163 Nr: 1, Ns: 2 4164 (packet lost) <- ICRP 4165 Nr: 3, Ns: 1 4167 (pause; LCCE A's timer started first, so fires first) 4169 ICRQ -> 4170 Nr: 1, Ns: 2 4172 (Realizing that it has already seen this packet, 4173 LCCE B discards the packet and sends an ACK message) 4175 <- ACK 4176 Nr: 3, Ns: 2 4178 (LCCE B's retransmit timer fires) 4180 <- ICRP 4181 Nr: 3, Ns: 1 4182 ICCN -> 4183 Nr: 2, Ns: 3 4185 <- ACK 4186 Nr: 4, Ns: 2 4188 Appendix C: Processing Sequence Numbers 4190 The Default L2-Specific Sublayer, defined in Section 4.6, provides a 4191 24-bit field for sequencing of data packets within an L2TP session. 4192 L2TP data packets are never retransmitted, so this sequence is used 4193 only to detect packet order, duplicate packets, or lost packets. 4195 The 24-bit Sequence Number field of the Default L2-Specific Sublayer 4196 contains a packet sequence number for the associated session. Each 4197 sequenced data packet that is sent must contain the sequence number, 4198 incremented by one, of the previous sequenced packet sent on a given 4199 L2TP session. Upon receipt, any packet with a sequence number equal 4200 to or greater than the current expected packet (the last received 4201 in-order packet plus one) should be considered "new" and accepted. 4202 All other packets are considered "old" or "duplicate" and discarded. 4203 Note that the 24-bit sequence number space includes zero as a valid 4204 sequence number (as such, it may be implemented with a masked 32-bit 4205 counter if desired). All new sessions MUST begin sending sequence 4206 numbers at zero. 4208 Larger or smaller sequence number fields are possible with L2TP if an 4209 alternative format to the Default L2-Specific Sublayer defined in 4210 this document is used. While 24 bits may be adequate in a number of 4211 circumstances, a larger sequence number space will be less 4212 susceptible to sequence number wrapping problems for very high 4213 session data rates across long dropout periods. The sequence number 4214 processing recommendations below should hold for any size sequence 4215 number field. 4217 When detecting whether a packet sequence number is "greater" or 4218 "less" than a given sequence number value, wrapping of the sequence 4219 number must be considered. This is typically accomplished by keeping 4220 a window of sequence numbers beyond the current expected sequence 4221 number for determination of whether a packet is "new" or not. The 4222 window may be sized based on the link speed and sequence number space 4223 and SHOULD be configurable with a default equal to one half the size 4224 of the available number space (e.g., 2^(n-1), where n is the number 4225 of bits available in the sequence number). 4227 Upon receipt, packets that exactly match the expected sequence number 4228 are processed immediately and the next expected sequence number 4229 incremented. Packets that fall within the window for new packets may 4230 either be processed immediately and the next expected sequence number 4231 updated to one plus that received in the new packet, or held for a 4232 very short period of time in hopes of receiving the missing 4233 packet(s). This "very short period" should be configurable, with a 4234 default corresponding to a time lapse that is at least an order of 4235 magnitude less than the retransmission timeout periods of higher 4236 layer protocols such as TCP. 4238 For typical transient packet mis-orderings, dropping out-of-order 4239 packets alone should suffice and generally requires far less 4240 resources than actively reordering packets within L2TP. An exception 4241 is a case in which a pair of packet fragments are persistently 4242 retransmitted and sent out-of-order. For example, if an IP packet 4243 has been fragmented into a very small packet followed by a very large 4244 packet before being tunneled by L2TP, it is possible (though 4245 admittedly wrong) that the two resulting L2TP packets may be 4246 consistently mis-ordered by the PSN in transit between L2TP nodes. 4247 If sequence numbers were being enforced at the receiving node without 4248 any buffering of out-of-order packets, then the fragmented IP packet 4249 may never reach its destination. It may be worth noting here that 4250 this condition is true for any tunneling mechanism of IP packets that 4251 includes sequence number checking on receipt (i.e., GRE [RFC2890]). 4253 Utilization of a Data Sequencing Level (see Section 5.4.3) of 1 (only 4254 non-IP data packets require sequencing) allows IP data packets being 4255 tunneled by L2TP to not utilize sequence numbers, while utilizing 4256 sequence numbers and enforcing packet order for any remaining non-IP 4257 data packets. Depending on the requirements of the link layer being 4258 tunneled and the network data traversing the data link, this is 4259 sufficient in many cases to enforce packet order on frames that 4260 require it (such as end-to-end data link control messages), while not 4261 on IP packets that are known to be resilient to packet reordering. 4263 If a large number of packets (i.e., more than one new packet window) 4264 are dropped due to an extended outage or loss of sequence number 4265 state on one side of the connection (perhaps as part of a forwarding 4266 plane reset or failover to a standby node), it is possible that a 4267 large number of packets will be sent in-order, but be wrongly 4268 detected by the peer as out-of-order. This can be generally 4269 characterized for a window size, w, sequence number space, s, and 4270 number of packets lost in transit between L2TP endpoints, p, as 4271 follows: 4273 If s > p > w, then an additional (s - p) packets that were otherwise 4274 received in-order, will be incorrectly classified as out-of-order and 4275 dropped. Thus, for a sequence number space, s = 128, window size, w 4276 = 64, and number of lost packets, p = 70; 128 - 70 = 58 additional 4277 packets would be dropped after the outage until the sequence number 4278 wrapped back to the current expected next sequence number. 4280 To mitigate this additional packet loss, one MUST inspect the 4281 sequence numbers of packets dropped due to being classified as "old" 4282 and reset the expected sequence number accordingly. This may be 4283 accomplished by counting the number of "old" packets dropped that 4284 were in sequence among themselves and, upon reaching a threshold, 4285 resetting the next expected sequence number to that seen in the 4286 arriving data packets. Packet timestamps may also be used as an 4287 indicator to reset the expected sequence number by detecting a period 4288 of time over which "old" packets have been received in-sequence. The 4289 ideal thresholds will vary depending on link speed, sequence number 4290 space, and link tolerance to out-of-order packets, and MUST be 4291 configurable. 4293 Editors' Addresses 4295 Jed Lau 4296 cisco Systems 4297 170 W. Tasman Drive 4298 San Jose, CA 95134 4300 EMail: jedlau@cisco.com 4302 W. Mark Townsley 4303 cisco Systems 4305 EMail: mark@townsley.net 4307 Ignacio Goyret 4308 Lucent Technologies 4310 EMail: igoyret@lucent.com 4312 Full Copyright Statement 4314 Copyright (C) The Internet Society (2004). 4316 This document is subject to the rights, licenses and restrictions 4317 contained in BCP 78, and except as set forth therein, the authors 4318 retain all their rights. 4320 This document and the information contained herein are provided on an 4321 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4322 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4323 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4324 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4325 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4326 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4328 Intellectual Property 4330 The IETF takes no position regarding the validity or scope of any 4331 Intellectual Property Rights or other rights that might be claimed to 4332 pertain to the implementation or use of the technology described in 4333 this document or the extent to which any license under such rights 4334 might or might not be available; nor does it represent that it has 4335 made any independent effort to identify any such rights. Information 4336 on the IETF's procedures with respect to rights in IETF Documents can 4337 be found in BCP 78 and BCP 79. 4339 Copies of IPR disclosures made to the IETF Secretariat and any 4340 assurances of licenses to be made available, or the result of an 4341 attempt made to obtain a general license or permission for the use of 4342 such proprietary rights by implementers or users of this 4343 specification can be obtained from the IETF on-line IPR repository at 4344 http://www.ietf.org/ipr. 4346 The IETF invites any interested party to bring to its attention any 4347 copyrights, patents or patent applications, or other proprietary 4348 rights that may cover technology that may be required to implement 4349 this standard. Please address the information to the IETF at ietf- 4350 ipr@ietf.org. 4352 Acknowledgement 4354 Funding for the RFC Editor function is currently provided by the 4355 Internet Society.