idnits 2.17.1 draft-ietf-l2tpext-l2vpn-04.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 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 601. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 585. ** 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. 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (June 2005) is 6890 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: 'RFC 2119' is mentioned on line 47, but not defined Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Wei Luo 3 Internet Draft Cisco Systems, Inc. 4 June 2005 6 L2VPN Extensions for L2TP 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The Layer 2 Tunneling Protocol (L2TP) provides a standard method for 34 setting up and managing L2TP sessions to tunnel a variety of L2 35 protocols. One of the reference models supported by L2TP describes 36 the use of an L2TP session to connect two Layer 2 circuits attached 37 to a pair of peering LACs, which is a basic form of Layer 2 Virtual 38 Private Network (L2VPN). This document defines the protocol 39 extensions for L2TP to set up different types of L2VPN in a unified 40 fashion. 42 Specification of Requirements 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in [RFC 2119]. 48 Table of Contents 50 Status of this Memo.......................................... 1 52 1. Introduction.............................................. 3 54 2. Network Reference Model................................... 3 56 3. Forwarder Identifier...................................... 4 58 4. Protocol Components....................................... 5 59 4.1 Control Messages...................................... 5 60 4.2 Existing AVPs for L2VPN............................... 5 61 4.3 New AVPs for L2VPN.................................... 6 63 5. Signaling Procedures...................................... 8 64 5.1 Overview.............................................. 8 65 5.2 Pseudowire Tie Detection.............................. 9 66 5.3 Generic Algorithm..................................... 9 68 6. IANA Considerations....................................... 13 70 7. Security Considerations................................... 14 72 8. Intellectual Property Statement........................... 14 74 9. Copyright Notice.......................................... 14 76 10. Acknowledgement.......................................... 15 78 11. References............................................... 15 79 11.1 Normative References................................. 15 80 11.2 Informative References............................... 15 82 12. Authors' Address......................................... 15 84 1. Introduction 86 [L2TPv3] defines a dynamic tunneling mechanism to carry multiple L2 87 protocols besides PPP (as originally defined in [RFC 2661]) over a 88 packet-based network. The baseline protocol supports various types 89 of applications, which have been highlighted in the different L2TP 90 reference models in [L2TPv3]. L2VPN applications are typically in 91 the scope of the LAC-LAC reference model. 93 This document discusses the commonalities as well as differences 94 among L2VPN applications with respect to utilizing L2TPv3 as the 95 signaling protocol. 97 The acronym "L2TP" refers to L2TPv3 or L2TP in general in this 98 document. 100 2. Network Reference Model 102 In the LAC-LAC reference model, a LAC serves as a cross-connect 103 between attachment circuits and L2TP sessions. Each L2TP session 104 acts as an emulated circuit, also known as pseudowire. A pseudowire 105 is used to bind two "forwarders" together. For different L2VPN 106 applications, different types of forwarders are defined. 108 In the L2VPN framework [L2VPN FW], a LAC is a Provider Edge (PE) 109 device. LAC and PE are interchangeable terms in the context of this 110 document. Remote systems in the LAC-LAC reference model are Customer 111 Edge (CE) devices. 113 +----+ L2 +----+ +----+ L2 +----+ 114 | CE |------| PE |....[core network]....| PE |------| CE | 115 +----+ +----+ +----+ +----+ 117 |<- emulated service ->| 118 |<----------------- L2 service -------------->| 120 L2VPN Network Reference Model 122 In a simple cross-connect application, an attachment circuit is a 123 forwarder directly bound to a pseudowire. It is a one-to-one 124 mapping. Traffic received from the attachment circuit on a local PE 125 is forwarded to the remote PE through the pseudowire. When the 126 remote PE receives traffic from the pseudowire, it forwards the 127 traffic to the corresponding attachment circuit on its end. The 128 forwarding decision is based on the attachment circuit or pseudowire 129 demultiplexing identifier. 131 With Virtual Private LAN Service (VPLS), a Virtual Switching Instance 132 (VSI) is a forwarder connected to one or more attachment circuits and 133 pseudowires. A single pseudowire is used to connect a pair of VSIs 134 on two peering PEs. Traffic received from an attachment circuit or a 135 pseudowire is first forwarded to the corresponding VSI based on the 136 attachment circuit or pseudowire demultiplexing identifier. The VSI 137 performs additional lookup to determine where to further forward the 138 traffic. 140 With Virtual Private Wire Service (VPWS), attachment circuits are 141 grouped into "colored pools". Each pool is a forwarder and connected 142 through a network of point-to-point cross-connect. The data 143 forwarding perspective is identical to the cross-connect application. 144 However, constructing colored pools involves more complicated 145 signaling procedures. 147 3. Forwarder Identifier 149 A forwarder identifier is assigned to each forwarder on a given PE 150 and is unique in the context of the PE. It is defined as the 151 concatenation of an Attachment Group Identifier (AGI) and an 152 Attachment Individual Identifier (AII), denoted as . The 153 AGI is used to group a set of forwarders together for signaling 154 purpose. An AII is used to distinguish forwarders within a group. 155 AII can be unique at a per platform or per group basis. 157 As far as the signaling procedures are concerned, a forwarder 158 identifier is an arbitrary string of bytes. It is up to 159 implementations to decide the values for AGI and AII. 161 When connecting two forwarders together, both MUST have the same AGI 162 as part of their forwarder identifiers. The AII of the source 163 forwarder is known as the Source AII (SAII), and the AII of the 164 target forwarder is known as the Target AII (TAII). Therefore, 165 source forwarder and target forwarder can be denoted as 166 and respectively. 168 4. Protocol Components 170 4.1 Control Messages 172 L2TP defines two sets of session management procedures: incoming call 173 and outgoing call. Even though it is entirely possible to use the 174 outgoing call procedures to signaling L2VPNs, the incoming call 175 procedures has some advantages in terms of the relevance of the 176 semantics. [PWE3L2TP] gives more details on why the incoming call 177 procedures are more appropriate for setting up pseudowires. 179 The signaling procedures for L2VPNs described in the following 180 sections are based on the Incoming Call procedures. 182 4.2 Existing AVPs for L2VPN 184 Router ID 186 The Router ID sent in SCCRQ and SCCRP during control connection setup 187 establishes the unique identity of each PE. 189 Pseudowire Capabilities List 191 The Pseudowire Capabilities List sent in the SCCRQ and SCCRP 192 indicates the pseudowire types supported by the sending PE. It 193 merely serves as an advertisement to the receiving PE. Its content 194 should not affect the control connection setup. 196 Before a local PE initiates a session of a particular pseudowire type 197 to a remote PE, it MUST examine whether the remote PE has advertised 198 this pseudowire type in this AVP, and SHOULD NOT attempt to initiate 199 the session if the intended pseudowire type is not supported by the 200 remote PE. 202 Pseudowire Type 204 The Pseudowire Type sent in ICRQ signals the intended pseudowire type 205 to the receiving PE. The receiving PE checks it against its local 206 pseudowire capabilities list. If it finds a match, it responds with 207 an ICRP without a Pseudowire Type AVP, which implicitly acknowledges 208 its acceptance of the intended pseudowire. If it does not find a 209 match, it MUST respond with a CDN with an "unsupported pseudowire 210 type" result code. 212 L2-Specific Sublayer 214 The L2-Specific Sublayer can be sent in ICRQ, ICRP, and ICCN. If the 215 receiving PE supports the specified L2-Specific Sublayer, it MUST 216 include the identified L2-Specific Sublayer in its data packets sent 217 to the sending PE. Otherwise, it MUST reject the connection by 218 sending a CDN to the sending PE. 220 Circuit Status 222 The Circuit Status is sent in both ICRQ and ICRP to inform the 223 receiving PE about the circuit status on the sending PE. It can also 224 be sent in ICCN and SLI to update the status. 226 Remote End Identifier 228 The TAII value is encoded in the Remote End ID AVP and sent in ICRQ 229 along with the optional AGI to instruct the receiving PE to bind the 230 proposed pseudowire to the forwarder that matches the specified 231 forwarder identifier. 233 4.3 New AVPs for L2VPN 235 Attachment Group Identifier 237 The AGI AVP, Attribute Type TBA, is an identifier used to associate a 238 forwarder to a logical group. The AGI AVP is used in conjunction 239 with the Local End ID AVP and Remote End ID AVP, which encode the 240 SAII and TAII respectively, to identify a specific forwarder. When 241 the AGI AVP is omitted in the control messages or contains a zero- 242 length value, the forwarders are considered using the default AGI. 243 Note that there is only one designated default AGI value for all 244 forwarders. 246 The Attribute Value field for this AVP has the following format: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 |M|H|0|0|0|0| Length | 0 | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | TBA | AGI (variable length) | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 The AGI field is a variable-length field. This AVP MAY be present in 257 ICRQ. 259 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 260 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6 261 plus the length of the AGI field. 263 Local End ID 264 The Local End ID AVP, Attribute Type TBA, encodes the SAII value. 265 The SAII may also be used in conjunction with the TAII to detect 266 pseudowire ties. When it is omitted in the control messages, it is 267 assumed that it has the same value as the TAII. 269 The Attribute Value field for this AVP has the following format: 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 |M|H|0|0|0|0| Length | 0 | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | TBA | SAII (variable length) | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 The SAII field is a variable-length field. This AVP MAY be present 280 in ICRQ. 282 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 283 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6 284 plus the length of the SAII field. 286 Interface Maximum Transmission Unit 288 The Interface Maximum Transmission Unit (MTU) AVP, Attribute Type 289 TBA, indicates the MTU in octets of a packet that can be sent out 290 from the CE-facing interface. The MTU values of a given pseudowire, 291 if advertised in both directions, MUST be identical. If they do not 292 match, the pseudowire SHOULD NOT be established. When this AVP is 293 omitted in the control messages in either direction, it is assumed 294 that the remote PE has the same interface MTU as the local PE for the 295 pseudowire being signaled. 297 The Attribute Value field for this AVP has the following format: 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 |M|H|0|0|0|0| Length | 0 | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | TBA | Interface MTU | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 The Interface MTU is a 2-octet value. This AVP MAY be present in 308 ICRQ and ICRP. When a PE receives an Interface MTU AVP with an MTU 309 value different from its own, it MAY respond with a CDN with a new 310 result code indicating the disconnect cause. 312 RC-TBA-1 - Mismatching interface MTU 314 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 315 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 8. 317 5. Signaling Procedures 319 5.1 Overview 321 Assume a PE assigns a forwarder identifier to one of its local 322 forwarders, and knows it needs to set up a pseudowire to a remote 323 forwarder on a remote PE that has a certain Forwarder ID. This 324 knowledge can be obtained either through manual configuration or some 325 auto-discovery procedure. 327 Before establishing the intended pseudowire, each pair of peering PEs 328 exchanges control connection messages to establish a control 329 connection. Each advertises its supported pseudowire types in the 330 Pseudowire Capabilities List AVP. 332 After the control connection is established, the local PE examines 333 whether the remote PE supports the pseudowire type it intends to set 334 up. Only if the remote PE supports the intended pseudowire type, it 335 should initiate a pseudowire connection request. 337 When the local PE receives an ICRQ for a pseudowire connection, it 338 examines the forwarder identifier encoded in the AGI, SAII, and TAII 339 in order to determine the following: 341 - whether it has a local forwarder with the forwarder identifier 342 value specified in the ICRQ, 344 - whether the remote forwarder with the forwarder identifier 345 specified in the ICRQ is allowed to connect with this local 346 forwarder. 348 If both conditions are met, it sends an ICRP to the remote PE to 349 accept the connection request. If either of the two conditions 350 fails, it sends a CDN to the remote PE to reject the connection 351 request. 353 The local PE can optionally include a result code in the CDN to 354 indicate the disconnect cause. The possible result codes are: 356 RC-TBA-2 - Attempt to connect to non-existent forwarder 357 RC-TBA-3 - Attempt to connect to unauthorized forwarder 359 5.2 Pseudowire Tie Detection 361 Conceivably in the network reference models, as either PE may 362 initiate a pseudowire to another PE at any time, the PEs could end up 363 initiating a pseudowire to each other simultaneously. In order to 364 avoid setting up duplicated pseudowires between two forwarders, each 365 PE must be able to independently detect such a pseudowire tie. The 366 following procedures need to be followed to detect a tie: 368 If both TAII and SAII are present in the ICRQ, the receiving PE 369 compares the TAII and SAII against the SAII and TAII itself 370 previously sent to the sending PE. If the received TAII matches the 371 sent SAII and the received SAII matches the sent TAII, a tie is 372 detected. 374 If only the TAII is present in the ICRQ, the SAII is assumed to have 375 the same value as the TAII. The receiving PE compares the received 376 TAII with the SAII that it previously sent to the sending PE. If the 377 SAII in that ICRQ is also omitted, then the value encoded in the sent 378 TAII is used for comparison. If they match, a tie is detected. 380 If the AGI is present, it is first prepended to the TAII and SAII 381 values before the tie detection occurs. 383 Once a tie has been discovered, the standard L2TP tie breaking 384 procedure is used to disconnect the duplicated pseudowire. 386 5.3 Generic Algorithm 388 The following uses a generic algorithm to illustrate the protocol 389 interactions when constructing an L2VPN using L2TP signaling. 391 Each PE first forms a list, SOURCE_FORWARDERS, consisting of all 392 local forwarders of a given VPN. Then it puts all local forwarders 393 that need to be interconnected and all remote forwarders of the same 394 VPN into another list, TARGET_FORWARDERS. The formation of the 395 network topology depends on the content in the SOURCE_FORWARDERS and 396 TARGET_FORWARDERS lists. These two lists can be constructed by 397 manual configuration and/or some auto-discovery procedure. 399 The algorithm is used to set up pseudowires among all the forwarders 400 that intend to be interconnected by iterating through each source and 401 target forwarder. An L2VPN is formed upon finishing the algorithm in 402 every participating PE of this L2VPN. 404 1. Pick the next forwarder, from SOURCE_FORWARDERS. If no 405 forwarder is available for processing, the processing is 406 complete. 408 2. Pick the next forwarder, from TARGET_FORWARDERS. If no 409 forwarder is available for processing, go back to step 1. 411 3. If the two forwarders are associated with different Router 412 IDs, a pseudowire must be established between them. Proceed 413 to step 6. 415 4. Compare the values of the two forwarders. If 416 they match, the source and target forwarders are the same, 417 so no more action is necessary. Go back to step 2. 419 5. As the source and target forwarders both reside on the local 420 PE, no pseudowire is needed. The PE simply creates a local 421 cross-connect between the two forwarders. Go back to step 2. 423 6. As the source and target forwarders reside on different PEs, 424 a pseudowire must be established between them. The PE first 425 examines if the source forwarder has already established a 426 pseudowire to the target forwarder. If so, go back to step 2. 428 7. If no pseudowire is already established between the source and 429 target forwarders, the local PE obtains the address of the 430 remote PE, and establishes a control connection to the remote 431 PE if one does not already exist. 433 8. The local PE sends an ICRQ to the remote PE. The AGI, TAII, 434 and SAII values are encoded in the AGI AVP, the Remote End ID 435 AVP, and the Local End ID AVP respectively. 437 9. If the local PE receives a response corresponding to the 438 ICRQ it just sent, proceed to step 10. Otherwise, if the 439 local PE receives an ICRQ from the same remote PE, proceed 440 to step 11. 442 10. The local PE receives a response from the remote PE. If 443 it is a CDN, go back to step 2. If it's an ICRP, the local 444 PE binds the source forwarder to the pseudowire and sends 445 an ICCN to the remote PE. Go back to step 2. 447 11. If the local PE receives an ICRQ from the same remote PE, 448 it needs to perform session tie detection, as described in 449 Section 5.2. If a session tie is detected, the PE performs 450 tie breaking. 452 12. If the local PE loses the tie breaker, it sends a CDN with 453 the result code that indicates the disconnection is due to 454 losing the tie breaker. Proceed to step 14. 456 13. If the local PE wins the tie breaker, it ignores the remote 457 PE's ICRQ, but acknowledges receipt of the control message 458 and continues waiting for the response from the remote PE. 459 Go to step 10. 461 14. The local PE determines whether it should accept the 462 connection request, as described in the Section 5.1. 463 If it accepts the ICRQ, it sends an ICRP to the remote PE. 465 15. The local PE receives a response from the remote PE. If 466 it is a CDN, go back to step 2. If it is an ICCN, the local 467 PE binds the source forwarder to the pseudowire, go back 468 to step 2. 470 The following diagram illustrates the above procedure: 472 ---------> Pick Next 473 | Source Forwarder 474 | | 475 | | 476 | v N 477 | Found Source Forwarder? ----------> End 478 | | 479 | Y | 480 | v 481 | Pick Next <-------------------------------- 482 | Target Forwarder | 483 | | | 484 | | | 485 | N v | 486 -------- Found Target Forwarder? | 487 | | 488 Y | | 489 v Y Y | 490 Same Router ID? ------> Same Forwarder ID? ------| 491 | | | 492 N | N | | 493 | v | 494 | Create Local -------| 495 v Cross-connect | 496 Pseudowire Already Y | 497 Established Between -------------------------------| 498 Source and Target? | 499 | | 500 N | | 501 v | 502 Local Initiates Pseudowire | 503 Connection Request to Remote | 504 | | 505 | | 506 v | 507 -------> Local Wait for Message | 508 | ----- from Remote -------------- | 509 | | | | 510 | | | | 511 | v v | 512 | Local Receives Pseudowire Local Receives Pseudowire | 513 | Connection Request Connection Response | 514 | from Remote from Remote | 515 | | | | 516 | | | | 517 | v v N | 518 | Perform Pseudowire Connection Accepted? --------| 519 | Tie Detection | | 520 | | Y | | 521 | | v | 522 | | Local Binds Source ---------| 523 | | Forwarder to Pseudowire | 524 | | | 525 | v N N | 526 | Tie Detected? -----> Accept Remote -----> Reject ------| 527 | | Connection Request? Remote Request | 528 | Y | ^ | | 529 | v | | Y | 530 | Perform Tie Breaking | ------> Local Binds ---- 531 | | | Source Forwarder 532 | | | to Pseudowire 533 | v N | 534 | Won Tie Breaking? ------> Disconnect 535 | | Local Connection 536 | Y | 537 | v 538 ------ Ignore Remote 539 Connection Request 541 6. IANA Considerations 543 This document defines three new L2TP control message Attribute Value 544 Pairs (AVPs) to be assigned by the IANA. These are described in 545 Section 4.3 are summarized below: 547 AVP-TBA-1 - Attachment Group Identifier 548 AVP-TBA-2 - Local End Identifier 549 AVP-TBA-3 - Interface Maximum Transmission Unit 551 Section 4.3 and Section 5.1 define three new result codes for the CDN 552 message are to be assigned by the IANA: 554 RC-TBA-1 - Mismatching interface MTU 555 RC-TBA-2 - Attempt to connect to non-existent forwarder 556 RC-TBA-3 - Attempt to connect to unauthorized forwarder 558 7. Security Considerations 560 The signaling procedures described in this document does not incur 561 additional security considerations that L2TP already provisions. 563 8. Intellectual Property Statement 565 The IETF takes no position regarding the validity or scope of any 566 Intellectual Property Rights or other rights that might be claimed to 567 pertain to the implementation or use of the technology described in 568 this document or the extent to which any license under such rights 569 might or might not be available; nor does it represent that it has 570 made any independent effort to identify any such rights. Information 571 on the procedures with respect to rights in RFC documents can be 572 found in BCP 78 and BCP 79. 574 Copies of IPR disclosures made to the IETF Secretariat and any 575 assurances of licenses to be made available, or the result of an 576 attempt made to obtain a general license or permission for the use of 577 such proprietary rights by implementers or users of this 578 specification can be obtained from the IETF on-line IPR repository at 579 http://www.ietf.org/ipr. 581 The IETF invites any interested party to bring to its attention any 582 copyrights, patents or patent applications, or other proprietary 583 rights that may cover technology that may be required to implement 584 this standard. Please address the information to the IETF at ietf- 585 ipr@ietf.org. 587 9. Copyright Notice 589 Copyright (C) The Internet Society (2005). 591 This document is subject to the rights, licenses and restrictions 592 contained in BCP 78, and except as set forth therein, the authors 593 retain all their rights. 595 This document and the information contained herein are provided on an 596 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 597 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 598 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 599 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 600 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 601 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 603 10. Acknowledgement 605 The author would like to thank Mark Townsley and Carlos Pignataro for 606 their valuable input. 608 11. References 610 11.1 Normative References 612 [L2TPv3] J. Lau et. al., "Layer Two Tunneling Protocol - Version 3 613 (L2TPv3)", RFC 3931, March 2005 615 11.2 Informative References 617 [L2VPN FW] L. Andersson et. al., "PPVPN L2 Framework", 618 draft-ietf-l2vpn-l2-framework-05.txt, June 2004 620 [PWE3L2TP] W. Townsley, "Pseudowires and L2TPv3", 621 draft-townsley-pwe3-l2tpv3-01.txt, June 2003 623 [RFC 2661] W. Townsley et. al., "Layer 2 Tunnel Protocol (L2TP)", 624 RFC 2661, August 1999. 626 12. Authors' Address 628 Wei Luo 629 Cisco Systems, Inc. 630 170 West Tasman Drive 631 San Jose, CA 95134 632 Email: luo@cisco.com