idnits 2.17.1 draft-townsley-pwe3-l2tpv3-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7621 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3193' is mentioned on line 625, but not defined == Unused Reference: 'RFC2119' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 693, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-08) exists of draft-ietf-pwe3-requirements-02 == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-02 == Outdated reference: A later version (-08) exists of draft-ietf-l2tpext-l2tp-ppp-01 == Outdated reference: A later version (-03) exists of draft-ietf-l2tpext-l2tp-atm-02 == Outdated reference: A later version (-06) exists of draft-ietf-l2tpext-l2tphc-04 Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT W. M. Townsley 3 draft-townsley-pwe3-l2tpv3-01.txt cisco Systems 4 Category: Informational June 2003 5 Expires: December 2003 7 Pseudowires and L2TPv3 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (2002). All Rights Reserved. 33 Abstract 35 This document provides an overview of the Layer 2 Tunneling Protocol 36 (L2TPv3), presented in a manner which highlights its applicability 37 for Pseudo Wire Emulation Edge to Edge (PWE3). It is intended as a 38 guide for architects, new implementers, and those adding 39 functionality to L2TPv3 in support of new pseudowire types. 41 Contents 43 Status of this Memo.......................................... 1 44 1.0 Introduction.......................................... 2 45 1.2 L2TPv2 and L2TPv3.................................... 3 47 2. L2TP Tunneling Reference Models and Terminology.......... 3 48 2.1 LAC to LAC Reference Model............................ 4 49 2.2 LAC to LNS Reference Model............................ 4 50 2.3 The LAC and LNS in L2TP............................... 5 52 3. L2TP Control Plane Overview and General Applicability.... 5 53 3.1 L2TP Control Connection Establishment................ 6 54 3.2 L2TP Session Establishment........................... 7 55 3.3 Summary of Status and Maintenance Messages........... 7 56 3.4 Control Message Composition.......................... 9 57 3.5 Creating New Control Messages........................ 9 58 3.6 Advertising Support for Optional Features............ 10 59 3.7 Summary of Selected PWE3-Related Control Message AVPs 10 60 3.7.1 Session Establishment AVPs....................... 10 61 3.7.2 Control Connection Establishment AVPs............ 11 63 4. L2TP Data Packet Encapsulation........................... 11 64 4.1 L2TP over various PSNs............................... 11 65 4.2 L2TPv3 over IP....................................... 12 67 5. Security Considerations.................................. 14 69 6. IANA Considerations...................................... 15 71 7. Acknowledgements......................................... 15 73 8. Author's Address......................................... 15 75 9. References............................................... 15 77 Appendix A: L2TPv2 and L2TPv3................................ 16 79 Appendix B: "Incoming Calls" and "Outgoing Calls"............ 17 81 1.0 Introduction 83 L2TPv3 [L2TPv3] defines a protocol for setup, maintenance and 84 transport of individual pseudowires (PWs) across an IP network. A 85 collection of PWs may be employed to provide a full Layer 2 VPN 86 (L2VPN) service for a variety of circuit types types, including 87 Ethernet, Frame Relay, HDLC, PPP, ATM, AAL5, and others. 89 L2TPv3 consists of a control protocol and associated state machines 90 for dynamic establishment, maintenance and release of PWs, together 91 with the necessary encapsulation to carry multiple PWs between two 92 tunnel endpoints. In most cases, a given PW-type will operate over 93 L2TPv3 with very few additional protocol constructs beyond that 94 defined in [L2TPv3]. When significant additional PW-type-specific 95 protocol constructs are necessary, they should be defined in brief 96 companion documents. 98 This document focuses solely on how L2TPv3 is used to support 99 individual Pseudowires. Full L2VPN services including various 100 provisioning methods, auto-discovery, etc. is outside the scope of 101 this specific document. 103 1.2 L2TPv2 and L2TPv3 105 L2TP (Layer 2 Tunneling Protocol) [RFC2661] defines a method for 106 offloading layer 2 PPP frames from a circuit-switched network to a 107 packet-switched network (e.g. IP), while providing emulation of as 108 many of the characteristics of the native point-to-point link as 109 possible. 111 L2TP as defined in [RFC2661] is sometimes referred to now as 112 "L2TPv2," while the extended version supporting mutliple PW types 113 defined in [L2TPv3] is referred to as "L2TPv3" (for more information 114 on the similarities and differences between L2TPv2 and L2TPv3, see 115 Appendix A). The remainder of this document will refer simply to L2TP 116 in general unless contrasting specific features of L2TPv3 or L2TPv2 117 which may differ in function. 119 New L2TPv3 implementations with no intention of supporting PPP over 120 L2TPv2 may ignore RFC 2661 as the L2TPv3 specification is complete on 121 its own. However, there may be advantages to starting with an 122 available L2TPv2 implementation, and specific advice is given for 123 migration and coexistence with L2TPv2 in [L2TPv3]. 125 2. L2TP Tunneling Reference Models and Terminology 127 Section 2 of [L2TPv3] identifies several reference models for Layer 2 128 tunneling, and refers to L2TP-specific terminology for these. Two 129 important pieces of L2TP terminology to be aware of are the L2TP 130 Access Concentrator (LAC) and L2TP Network Server (LNS). This section 131 provides an overview of two of these reference models and terminology 132 in specific relation to support of PWs for PWE3. 134 2.1 LAC to LAC Reference Model 136 An L2TP LAC looks like a PWE3 PE. That is, there are "native" 137 circuits physically connected to the equipment, and pseudowires 138 extending from the LAC over a Packet Switched Network (PSN) for these 139 circuits. For L2TPv3, the default PSN is an IP network. 141 Following is a diagram of the "LAC to LAC" service model defined in 142 L2TPv3. This is very similar to the PWE3 Network Reference Model 143 [PWE3-REQ], though utilizing L2TP-specific nomenclature which 144 abstracts the protocol terminology from the deployment location. 146 +-----+ L2 +-----+ +-----+ L2 +-----+ 147 | |------| LAC |...[Packet Network]...| LAC |------| | 148 +-----+ +-----+ +-----+ +-----+ 149 Remote Remote 150 System System 151 |<- Emulated Service ->| 152 |<----------------- L2 Service ----------------->| 154 Figure 1: L2TP LAC to LAC Reference Model 156 LAC - L2TP Access Concentrator, analogous to the PWE3 PE. 158 Remote System - Analogous to the PWE3 CE. 160 Emulated Service - Analogous to the PWE3 pseudowire. 162 2.2 LAC to LNS Reference Model 164 An LNS is different from an LAC in that it does not have native 165 Attachment Circuits on which to directly forward pseudowire frames 166 to. Instead, the pseudowire frames are received and processed on a 167 virtual interface as if received on a local AC as a CE. A convenient 168 way to think of this is to imagine a PWE3 CE and PE collapsed into a 169 single piece of equipment. The LNS MAY support virtual routing or 170 bridging instances for groups of sessions. 172 An LNS may be used with an LAC to provide access to a network via 173 emulated L2 circuits. This is the most commonly used model in L2TPv2 174 deployments for PPP tunneling at the time of this writing. 176 +-----+ L2 +-----+ +-----+ 177 | |------| LAC |....[Packet Network]....| LNS |...[Home Network] 178 +-----+ +-----+ +-----+ 179 Remote 180 System 181 |<-- Emulated Service -->| 182 |<----------- L2 Service ------------>| 184 Figure 2: L2TP LAC to LNS Reference Model 186 LAC - L2TP Access Concentrator, analogous to the PWE3 PE. 188 Remote System - Analogous to the PWE3 CE. 190 LNS - L2TP Network Server, a PWE3 PE and CE collapsed into the same 191 device. 193 Emulated Service - Analogous to the PWE3 pseudowire. 195 2.3 The LAC and LNS in L2TP 197 From an encapsulation perspective, and during Control Connection 198 setup (described in section 4), L2TPv3 does not distinguish between 199 whether an LAC or LNS is on either side of the PW. During session 200 setup, there are some differences with regard to identification of 201 attachment circuits and the like as an LNS does not contain physical 202 circuits to attach to. For session setup, L2TPv2 makes more 203 reference to the LAC and LNS as very separate different devices, 204 while these differences were minimized in L2TPv3. 206 The remainder of this document will refer to the PWE3 terms "PE" and 207 "CE" when discussing PWE3 applicability, though it is important to 208 remember what an LAC, LNS, and Remote System are when reading the 209 L2TP Protocol Documents. 211 3. L2TP Control Plane Overview and General Applicability 213 The L2TP Control Plane is divided into two parts, (1) a reliable 214 Control Connection for sending control messages between PEs, and (2) 215 state machines for establishing, maintaining, and tearing down the 216 Control Connections and L2TP Sessions between each PE. 218 One L2TP Session is established for each pseudowire, and each Control 219 Connection governs a group of Sessions as well as the common 220 association between two PEs. There may be one or more Control 221 Connections between two PEs, and typically are many Sessions within 222 each Control Connection. It is important to note that L2TPv2 parlance 223 commonly referred to each established Control Connection as a 224 "Tunnel" which is somewhat different than the definition in PWE3. 225 L2TPv3 does away with "Tunnel" in its terminology to avoid obvious 226 confusion, referring only to "Sessions" and "Control Connections." 228 3.1 L2TP Control Connection Establishment 230 The L2TP Control Connection is the primary association between two 231 L2TP tunnel endpoints (PEs). A Control Connection must be established 232 before any L2TP Sessions (and hence pseudowires) may be established. 234 A successful Control Connection establishment looks like this: 236 PE A PE B 237 ------ ------ 238 SCCRQ -> 239 <- SCCRP 240 SCCCN -> 242 SCCRQ: Start Control Connection Request 243 SCCRP: Start Control Connection Reply 244 SCCCN: Start Control Connection Connected 246 Note that each of these messages is transported by the reliable 247 control channel (i.e., there is an additional transport-level ack to 248 the SCCCN that will occur, but this is a layer below the L2TP state 249 machine). Either side of a connection may initiate the Control 250 Connection by sending an SCCRQ, and a tie-breaker facility exists in 251 the event that both sides attempt connection establishment at the 252 same time. 254 During Control Connection establishment, PEs establish their identity 255 and exchange capability information with one another. Identity may be 256 confirmed via an optional challenge-handshake authentication exchange 257 built into the control connection setup. Capability and relevant 258 configuration information is advertised via AVPs in the SCCRQ or 259 SCCRP messages. 261 The protocol constructs described in this section provide the basis 262 for the following PWE3 requirements as identified in [PWE3-REQ]: 264 Misconnection and Payload Mistype (Section 3.3.2.) 265 Collective Status Notification (3.3.5.) 266 Tunnel Hierarchy (Scalability, Section 6.) 268 3.2 L2TP Session Establishment 270 Once the Control Connection is established, L2TP sessions 271 (pseudowires) may be established. L2TP has two state machines, and 272 two different sets of messages depending on the type of session to be 273 established. We will limit the discussion in this document to the 274 "Incoming Call" state machine and message exchange, as this is the 275 commonly used case in PWE3 (see Appendix B for a discussion of the 276 term "Call" and the "Outgoing Call" state machine and message 277 exchange). 279 A successful L2TP session establishment looks like this: 281 PE A PE B 282 ------ ------ 283 ICRQ -> 284 <- ICRP 285 ICCN -> 287 ICRQ: Incoming Call Request 288 ICRP: Incoming Call Reply 289 ICCN: Incoming Call Connected 291 During session establishment, characteristics of the individual 292 pseudowire, interfaces, etc. may be exchanged, as well as ephemeral 293 session attributes such as the Session ID used for data packet 294 switching. In the event that both sides of the connection attempt to 295 send an ICRQ at the same time, a tie-breaker AVP is used to determine 296 which side "wins." 298 The protocol constructs described in this section provide the basis 299 for the following PWE3 requirements as identified in [PWE3-REQ] 301 Setup and Teardown of Pseudo-Wires (Section 3.1.) 302 Misconnection and Payload Mistype (Section 3.3.2.) 304 3.3 Summary of Status and Maintenance Messages 306 All messages referred to here are sent as single independent 307 messages, requiring no explicit state machine to operate above the 308 reliable Control Connection. This section is intended to provide a 309 summary of available messages in the L2TPv3 specification. For more 310 details of each message, including AVPs used in the construction of 311 each, etc. please refer to [L2TPv3]. 313 Hello Message 315 The Hello message is used as a simple "keepalive" to ensure that 316 the peer is still active. If control and data operate over the 317 same path (as is the default for L2TPv3 over IP), then the 318 delivery of this message may be used as a general indicator that a 319 valid data path exists as well. This message is sent periodically 320 by either peer, based on a configured time period, and may back 321 off during periods of congestion or when other information (e.g. 322 receipt of another control message) is available to indicate that 323 a peer is still active. Thus, the Hello message is never 324 "expected" by either side of the link. Instead, the Hello 325 mechanism relies only on the generic Control Connection transport 326 for delivery. For added scalability, the Hello message acts as a 327 collective keepalive for all sessions associated with a given 328 Control Connection. 330 The Hello message MUST NOT be used to carry status notification 331 events, or other purposes beyond the scope of a simple peer and 332 path detection facility. 334 Set Link Info (SLI) Message 336 The Set Link Info message is used to identify link status changes 337 at a PE interface associated with a pseudowire. The most basic 338 link status change is simply a circuit going up or down, which is 339 advertised via the base Circuit Status AVP. Additional AVPs for 340 each service type may be defined if additional information 341 associated with an interface needs to be updated over the life of 342 a connection. These AVPs MUST be defined in separate service- 343 specific documents. 345 WAN Error Notify (WEN) Message 347 This message is used to identify any link interface or pseudowire 348 errors that may occur and be of interest to the operator on the 349 other side of the L2TP connection. This includes statistics on 350 packet loss, out-of-order delivery (if sequencing is enabled) and 351 packet corruption (if some form of CRC or Checksum is available). 352 These values MAY be reported on a periodic interval, and are for 353 logging and troubleshooting purposes. Any necessary values for a 354 given service beyond those defined in [L2TPv3] MUST be defined in 355 separate service-specific documents. 357 The protocol constructs described in this section provide the basis 358 for the following PWE3 requirements as identified in [PWE3-REQ]: 360 Status Monitoring (Section 3.2.) 361 Up/Down Notification (Section 3.3.1.) 362 Keep-alive (Section 3.4.) 363 Packet Loss, Corruption, and Out-of-order Delivery (Section 3.3.3.) 365 3.4 Control Message Composition 367 Control Messages are sent with the L2TP Control Connection header to 368 ensure proper delivery between PEs, followed by a list of Attribute 369 Value Pairs (AVPs). AVPs in L2TP are of a similar form to the "Type 370 Length Value" (TLV) constructs in other control protocols. The 371 Message Type itself is an AVP, as is the specific Session ID or 372 Control Connection ID for which the message applicable for. Please 373 refer to [L2TPv3] for the specific format of these AVPs and the 374 Control Message header. 376 3.5 Creating New Control Messages 378 Adding additional control messages to L2TP is a natural extension 379 that may be utilized to signal events and information between 380 pseudowire endpoints. Most line events and status notifications may 381 be sent with a single, independent control message. Additional 382 complexity via req/ack messages and state machines should be avoiding 383 when a single reliably delivered message will suffice. 385 A new message may be created by simply assigning a new Message Type 386 AVP value. The Message Type AVP is present at the beginning of the 387 body of all L2TP Control Messages. This AVP may be vendor-specific, 388 rendering the control message itself as vendor-specific. 390 The Vendor ID is zero for IETF defined messages, and set to the IANA 391 assigned "SMI Network Management Private Enterprise Codes" [RFC1700] 392 value for vendor-specific messages. IANA also assigns the Message 393 Type value for IETF Control Messages, but vendor-specific messages 394 must maintain their own number space. 396 L2TP Message Type AVP: 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 |1|0| rsvd | Length = 8 | Vendor ID (0 for IETF) | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Attribute Type = 0 | Message Type | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Figure 3: L2TP Message Type AVP 408 3.6 Advertising Support for Optional Features 410 The SCCRQ, SCCRP, and SCCCN messages should be utilized to advertise 411 availability of a specific optional feature available for the Control 412 Connection or the group of sessions within a Control Connection. This 413 may be as simple as the presence of a single AVP, or a set of AVPs 414 listing multiple parameters. 416 Support for a given pseudowire type MUST be advertised via the 417 Pseudowire Capabilities List AVP. 419 3.7 Summary of Selected PWE3-Related Control Message AVPs 421 This section will highlight some more pertinent AVPs used in the 422 setup and maintenance of pseudowires with L2TP. 424 3.7.1 Session Establishment AVPs 426 The following AVPs are among those exchanged during L2TP Session 427 establishment. For a complete list and full details, refer to section 428 5.4.4 of [L2TPv3]. 430 End Identifier AVP 432 The End Identifier AVP is of arbitrary length, and is used to 433 identify the interface, circuit, or other entity to tie the L2TP 434 session to. The field may be a simple 4-octet binary value, an 435 ASCII string, or any other agreed-upon format for the given 436 pseudowire type or application. 438 Pseudowire Type 440 The Pseudowire Type indicates the type of pseudowire for this L2TP 441 session. 443 Assigned Cookie 445 The 0, 32, or 64-bit random value to be sent in each data packet 446 for sanity checking the session context lookup. A 0-bit value is 447 used to indicate that the Cookie field is not present. 449 Local Session ID 451 Used to exchange the pair of 32-bit Session IDs that are to be 452 used in all data packet headers to identify an L2TP Session (and 453 hence a pseudowire). 455 3.7.2 Control Connection Establishment AVPs 457 The following AVPs are exchanged during Control Connection 458 establishment. For a complete list and full details, refer to section 459 5.4.3 of [L2TPv3]. 461 Pseudowire Capabilities List (SCCRP, SCCRQ) 463 List of pseudowire types that this node is capable of receiving 464 packets for. Used to advertise peer PE capabilities before 465 initiating a session. 467 Host Name (SCCRP, SCCRQ) 469 The Host Name AVP carries a unique identifier, possible a fully 470 qualified domain name, for the originator of the control 471 connection. 473 Challenge (SCCRP, SCCRQ) 475 Random data hashed with a shared password to perform a simple 476 Control Connection (PE to PE) authentication. 478 Challenge Response (SCCCN, SCCRP) 480 Result of the hash used for Control Connection (PE to PE) 481 authentication. 483 4. L2TP Data Packet Encapsulation 485 4.1 L2TP over various PSNs 487 L2TP was designed from its inception to be able to operate over any 488 packet-switched network (PSN). While UDP/IP is by far the most 489 popular PSN for L2TPv2 tunneling PPP, specifications for other PSNs 490 have been deployed [RFC3070], [L2TPAAL5] and is explicitly allowed in 491 [RFC2661]. 493 The L2TP control plane may also be used to setup alternate data 494 encapsulations. For example, [L2TPHC] defines a header format for a 495 specific application where the size of the L2TP and PPP header is of 496 primary importance. L2TPv3 takes advantage of this as well, signaling 497 its extended header format by the presence of the 32-bit Session ID 498 as opposed to the 16-bit Session ID for L2TPv2. Other PW Multiplexing 499 formats could be exchanged here as well, including an MPLS label, or 500 GRE Key. 502 4.2 L2TPv3 over IP 504 Following is the format of the L2TPv3 data header defined for 505 operation over IP Protocol ID 115. 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Session ID | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Cookie (opt) | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Cookie (opt) | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 |P|S|x|x|x|x|x|x| Sequence Number (opt) | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Figure 4: An L2TPv3 over IP Data Packet 521 The first four octets contain the L2TPv3 Session ID. The Session ID 522 is used as a pseudowire identifier/multiplexing field. It contains 523 32-bits assigned by the receiver during session establishment. The 524 expectation is that the receiver will optimize the bits in this 525 Session ID for whatever context lookup mechanism may be available on 526 the specific platform. For example, the context lookup mechanism for 527 the pseudowire could be a simple index with the low-order bits used 528 as a direct lookup, or specific bits could be used to distribute a 529 packet to parallel processing paths in a distributed engine, 530 platform, or cluster. If the following optional Cookie is utilized, 531 the Session ID may be selected without concern for choosing a value 532 which has been recently expired. The Session ID of 0 is reserved for 533 L2TPv3 control traffic. 535 The remainder of L2TPv3 header beyond the Session ID is optional, and 536 may even vary from what is shown above based upon the PW-type in 537 operation. The L2TP control channel signals the presence of (and in 538 many cases the values contained within) each field during session 539 establishment. In order to ensure interoperability while still 540 allowing some flexibility over what fields an implementation is 541 required to know how to process, L2TP uses a simple governing 542 principle for its variant header. This principle states that the 543 receiver of a data packet always identifies the format it expects, 544 and the sender MUST strictly comply. This is the case not only for 545 presence of optional fields such as the Cookie or L2-specific 546 sublayer, but for the contents of the Session ID and Cookie as well, 547 i.e., one side always informs the other exactly what it expects to be 548 present in a header. 550 The optional Cookie (0, 4 or 8 octets) is designed to be an 551 efficient, lightweight, packet validation mechanism. Like the Session 552 ID, it contains bits assigned by the receiver during session 553 establishment for insertion in each packet. Unlike the Session ID, 554 these bits do not serve as a context lookup mechanism, but rather as 555 a simple check to see if the value in the data packets matches the 556 value advertised for that Session. Also, unlike the Session ID, the 557 value selected for a Cookie MUST be unpredictable and unique across 558 current and recently-expired sessions. 560 Thus, while the form of the Session ID is free to be optimized for a 561 local lookup mechanism, the Cookie provides an added degree of 562 certainty that the arriving packet does in fact match the context 563 obtained by the Session ID resolution. For example, if the Session ID 564 context lookup for an arriving data packet was implemented as a 565 simple index, a single bit error in the range of bits being used for 566 the index could rather easily cause a packet to be sent to the wrong 567 PW or interface. Since there is no network-level checksum available 568 for the L2TP Session ID running directly over IP, this may be of 569 concern depending on the potential for unchecked bit errors of the 570 underlying data link. The Cookie provides up to a full 64 bits of 571 additional guarantee that a packet is definitively intended for a 572 given destination in face of such bit errors, as well as a way of 573 detecting the arrival of any stale data packets after a Session ID 574 has been released and reallocated. The Cookie also provides 575 protection against simple brute force or blind data insertion attacks 576 by a rogue entity. 578 The next four bytes in Figure 4 depict of the default L2-specific 579 sublayer for L2TPv3. These fields contain pseudowire-specific values, 580 and as such may vary among pseudowire types (e.g. RTP has its own 581 sequencing, thus a given timing-dependent pseudowire type may choose 582 to not use the default header defined here). 584 The P bit is a "priority" bit which SHOULD be set for end-to-end 585 signaling packets traversing the session data path. This allows the 586 PE to provide a higher priority to these packets when processing as 587 they may be important for the health of the overall end-to-end link. 588 This may be of particular concern during periods of congestion at the 589 PE if the native service being emulated has an end-to-end keepalive 590 method enabled. 592 The S bit indicates whether the following sequence number is valid or 593 not. 595 The Sequence number is a 24-bit free running counter (0 is a valid 596 sequence number). 598 The x bits are reserved for future use. 600 For further details of how these fields are used, please consult 601 [L2TPv3]. 603 The protocol constructs described in this section provide the basis 604 for the following PWE3 requirements as identified in [PWE3-REQ]: 606 Handling Control Messages of the Native Services (Section 2.5.) 607 Frame Duplication (Section 2.3.) 608 Frame Ordering (Section 2.2.) 609 Support of Multiplexing and Demultiplexing (Section 2.1.3) 610 Support of Variable Length PDUs (Section 2.1.2.) 612 5. Security Considerations 614 L2TP provides a number of security features which may be used 615 depending on the needs of a given deployment. Details of these are 616 provided in [L2TPv3]. 618 L2TP acts much like a client/server application operating between two 619 nodes on a network. Thus, the pseudowire which L2TP operates with 620 inherits many of the security properties of the underlying PSN (for 621 good or for ill). In cases where the PSN is protected, physically, 622 cryptographically, or otherwise, the pseudowire itself is also 623 protected. This is discussed further in [PWE3-PLD]. 625 [RFC3193] provides details on how to protect L2TPv2 with IPsec 626 transport mode. This is applicable to L2TPv3 over IPsec as well, 627 though the sections on UDP port "floating" may be ignored for the 628 IP-only encapsulation. When running over IP, L2TP with IPsec provides 629 cryptographic security for all data traffic within and control 630 traffic in support of the L2TP pseudowires. Running IPsec beneath 631 L2TP in this manner does not require any extensions to IPsec, and 632 does not rely on IPsec for Tunnel Mode encapsulation or any 633 extensions to the IPsec suite of protocols. 635 In the event that IPsec is not available, L2TP also provides a simple 636 shared-secret Control Connection Authentication method to ensure that 637 only authorized PE are permitted to establish a Control Connection 638 (and hence any pseudowire connections within). 640 L2TPv3 includes an optional 64-bit Cookie in the header of each L2TP 641 data packet which contains a random value identified at session 642 start. While not its only functional purpose, the cookie field may 643 be used to protect against blind insertion attacks for a given 644 tunnel. This is not intended as a replacement for proper traffic 645 filtering, nor for cryptographic security with IPsec when warranted. 647 However, in the absence of advanced traffic snooping, this field does 648 provide a reasonable defense against brute force packet insertion 649 attacks, and certainly provides for protection against 650 misconfiguration or other potential means of inadverdent packet 651 misdirection. 653 6. IANA Considerations 655 There are no new numbers defined in this document for IANA to 656 maintain. 658 7. Acknowledgements 660 I would like to acknowledge the author of the first Ethernet over 661 L2TP internet draft, Suhail Nanji, the first Frame Relay over L2TP 662 authors, Nishit Vasavada, Jim Boyle, Chris Garner, Serge Maskalik, 663 Vijay Gill, and the original "Encapsulation Services" authors for 664 L2TP, Nishit Vasavada, Danny McPherson, Ravi Bail Bhat, Andy 665 Koscinski, Chi Fai Ho. These individuals were among the original 666 purveyors of non-PPP encapsulations over L2TP before L2TPv3 and the 667 PWE3 Working Group was created. 669 Stewart Bryant, Eric Rosen, Lloyd Wood, and Wei Luo provided helpful 670 review of this document. 672 8. Author's Address 674 W. Mark Townsley 675 cisco Systems 676 7025 Kit Creek Road 677 PO Box 14987 678 Research Triangle Park, NC 27709 679 mark@townsley.net 681 9. References 683 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 684 1700, October 1994. See also: 685 http://www.iana.org/numbers.html 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", RFC 2119, March 1997. 690 [RFC2661] Townsley, Valencia, Rubens, Pall, Zorn, Palter, "Layer 691 Two Tunneling Protocol 'L2TP'", RFC 2661, June 1999. 693 [RFC2434] Alvestrand, H. and Narten, T., "Guidelines for Writing an 694 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 695 October 1998. 697 [RFC3070] V. Rawat, R. Tio, S. Nanji, R. Verma, "Layer Two Tunneling 698 Protocol (L2TP) over Frame Relay," RFC 3070, February 2001. 700 [PWE3-REQ] XiPeng Xiao, Danny McPherson, Prayson Pate, Craig White, 701 Kireeti Kompella, Vijay Gill, Thomas D. Nadeau, 702 "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)," 703 work in progress, draft-ietf-pwe3-requirements-02.txt, 704 May 2002. 706 [PWE3-PLD] Stewart Bryant, Lloyd Wood, Mark Townsley, Danny McPherson, 707 "Protocol Layering in PWE3," work in progress, 708 draft-bryant-pwe3-protocol-layer-01.txt, February 2002. 710 [L2TPv3] J. Lau, M. Townsley, A. Valencia, G. Zorn, I. Goyret, 711 G. Pall, A. Rubens, B. Palter, "Layer Two Tunneling Protocol 712 (Version 3) 'L2TPv3'" work in progress, 713 draft-ietf-l2tpext-l2tp-base-02.txt, February 2002. 715 [L2TP-PPP] J. Lau, M. Townsley, A. Valencia, G. Zorn, M. Verma, 716 I. Goyret, G. Pall, A. Rubens, B. Palter, "PPP Tunneling 717 Using Layer Two Tunneling Protocol" work in progress, 718 draft-ietf-l2tpext-l2tp-ppp-01.txt, November 2001. 720 [L2TPAAL5] Mike Davison, Arthur Lin, Ajoy Singh, John Stephens, 721 Rollins Turner, Rene Tio, Suhail Nanji, "L2TP over AAL5," 722 work in progress, draft-ietf-l2tpext-l2tp-atm-02.txt, 723 August 2001. 725 [L2TPHC] A. Valencia, "L2TP Header Compression ('L2TPHC')," 726 work in progress, draft-ietf-l2tpext-l2tphc-04.txt, 727 October 2001. 729 Appendix A: L2TPv2 and L2TPv3 731 L2TPv2 [RFC2661] was first deployed as a method for bypassing 732 expensive PSTN (Public Switching Telephone Network) networks with 733 faster, cheaper, IP networks. L2VPNs were created by tunneling point 734 to point PPP connections over IP (and to a lesser extent, Frame Relay 735 and ATM) networks to multiple service providers. As broadband DSL was 736 deployed, L2TP was used to offload PPP from ATM PVC networks, again 737 utilizing the ability to dynamically create emulated point-to-point 738 connections between any L2TP-enabled IP connected endpoint. More 739 recently, L2TP has been used to tunnel Ethernet and Frame Relay, 740 utilizing the familiar L2TP constructs for tunneling of PPP. 742 To provide specification modularity for tunneling pseudowire types 743 other than PPP, RFC 2661 was split into a base specification [L2TPv3] 744 and an accompanying PPP over L2TP specification [L2TP-PPP]. This base 745 specification also introduced a new encapsulation format for 746 transport directly over IP protocol ID 115 (as opposed to only UDP), 747 an expanded Session ID space from 16 to 32 bits, an extended sequence 748 number space from 16 to 32 bits, and other changes based on past 749 implementation experience. These changes required an L2TP version 750 field increment to 3, thus the name "L2TPv3" that has been adopted. 751 The L2TPv2 header over UDP port 1701 may still be used for tunneling 752 PPP as defined in [RFC2661], and likely will be for some time. Layer 753 2 tunneling other than PPP, MUST use the improved encapsulation 754 method defined in the L2TPv3 specification. 756 The L2TPv2 state machines, reliable transport for message delivery, 757 maintenance and status messages, etc. remain largely unchanged in 758 L2TPv3 beyond the separation of PPP-specific AVPs (Attribute Value 759 Pairs) from the base specification, and the addition of new AVPs to 760 support the negotiation of pseudowire types and their associated 761 connection to attached circuits. 763 For more information on the differences between L2TPv2 and L2TPv3, 764 please see Section 1.1, "Changes from RFC 2661" and Section 4.7, 765 "L2TPv2/v3 Interoperability and Migration" in [L2TPv3]. 767 Appendix B: "Incoming Calls" and "Outgoing Calls" 769 The term "Call" used in L2TP is a holdover from the action of 770 receiving a call on a dialup line. PWE3 was not the first to make 771 this original choice of wording seem a bit out of place; the very 772 common use of L2TP in broadband applies this same "call" action to an 773 ATM PVC. In this light, an L2TP "Incoming Call" becomes the action of 774 a circuit being provisioned and transitioning to the "Up" or "Active" 775 state. When looked at this way, it becomes a bit less awkward. The 776 choice to keep the "Call" name was made to be consistent with the 777 large installed base of existing implementations using this 778 terminology. 780 An "Outgoing Call" is very different from an "Incoming Call" in L2TP. 781 An "Outgoing Call" is SVC-type connection attempted in response to an 782 L2TP Outgoing Call Request (OCRQ), directed to an arbitrary location 783 identified by information contained in the L2TP message, and may take 784 some time to be completed. For example, the classic L2TPv2 Outgoing 785 Call application is dialing a modem on a PSTN based on a telephone 786 number. The node establishing the SVC connection acts as a slave to 787 the other side of the L2TP connection, establishing the SVC wherever 788 indicated (within policy bounds which may be applied if necessary). 790 The Outgoing Call message exchange has a very clear initiator and 791 responder, incapable of a "tie" as is the case in an Incoming Call 792 exchange. Also, instead of three messages sent in response to one 793 another in a handshake fashion as with an Incoming Call, an Outgoing 794 Call is established by sending a single message from the initiator, 795 and two messages sent from the responder in return. The first 796 Outgoing Call message, the OCRQ, is sent to request the Outgoing Call 797 to be made with the identified SVC method. The subsequent two 798 messages, the Outgoing Call Reply (OCRQ) and Outgoing Call Connected 799 (OCRP) messages signal that the SVC connection is being attempted, 800 and that the SVC connection was completed, respectivly. 802 Thus, an Outgoing Call is essentially a method of controlling the 803 originating point of an SVC, allowing it to be established from any 804 reachable L2TP-enabled device able to perform outgoing calls. PWE3 805 has largely identfied incorporation of various SVC methods as "left 806 for future study." Until said future study is completed, the 807 Outgoing Call model may not find use outside of the dial arena where 808 it is deployed with L2TPv2 today. 810 Full Copyright Statement 812 Copyright (C) The Internet Society (2002). All Rights Reserved. 814 This document and translations of it may be copied and furnished to 815 others, and derivative works that comment on or otherwise explain it 816 or assist in its implementation may be prepared, copied, published 817 and distributed, in whole or in part, without restriction of any 818 kind, provided that the above copyright notice and this paragraph are 819 included on all such copies and derivative works. However, this 820 document itself may not be modified in any way, such as by removing 821 the copyright notice or references to the Internet Society or other 822 Internet organizations, except as needed for the purpose of 823 developing Internet standards in which case the procedures for 824 copyrights defined in the Internet Standards process must be 825 followed, or as required to translate it into languages other than 826 English. 828 The limited permissions granted above are perpetual and will not be 829 revoked by the Internet Society or its successors or assigns. 831 This document and the information contained herein is provided on an 832 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 833 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 834 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 835 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 836 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."