idnits 2.17.1 draft-ietf-l2tpext-l2vpn-02.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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 581. ** 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. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 == Line 162 has weird spacing: '...part of their...' == 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 (October 2004) is 7126 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 == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-14 Summary: 9 errors (**), 0 flaws (~~), 6 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 October 2004 6 L2VPN Extensions for L2TP 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668. 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. Full Copyright Statement.................................. 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 an L2 packet, excluding L2TP 290 encapsulation, that can be sent out from the CE-facing interface. 291 The MTU values of a given pseudowire, if advertised in both 292 directions, MUST be identical. If they do not match, the pseudowire 293 SHOULD NOT be established. When it is omitted in the control 294 messages in either direction, it is assumed that the remote PE has 295 the same interface MTU as the local PE for the pseudowire being 296 signaled. 298 The Attribute Value field for this AVP has the following format: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 |M|H|0|0|0|0| Length | 0 | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | TBA | Interface MTU | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 The Interface MTU is a 2-octet value. This AVP MAY be present in 309 ICRQ and ICRP. 311 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 312 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 8. 314 5. Signaling Procedures 316 5.1 Overview 318 Assume a PE assigns a forwarder identifier to one of its local 319 forwarders, and knows it needs to set up a pseudowire to a remote 320 forwarder on a remote PE that has a certain Forwarder ID. This 321 knowledge can be obtained either through manual configuration or some 322 auto-discovery procedure. 324 Before establishing the intended pseudowire, each pair of peering PEs 325 exchanges control connection messages to establish a control 326 connection. Each advertises its supported pseudowire types in the 327 Pseudowire Capabilities List AVP. 329 After the control connection is established, the local PE examines 330 whether the remote PE supports the pseudowire type it intends to set 331 up. Only if the remote PE supports the intended pseudowire type, it 332 should initiate a pseudowire connection request. 334 When the local PE receives an ICRQ for a pseudowire connection, it 335 examines the forwarder identifier encoded in the AGI, SAII, and TAII 336 in order to determine the following: 338 - whether it has a local forwarder with the forwarder identifier 339 value specified in the ICRQ, 341 - whether the remote forwarder with the forwarder identifier 342 specified in the ICRQ is allowed to connect with this local 343 forwarder. 345 If both conditions are met, it sends an ICRP to the remote PE to 346 accept the connection request. If either of the two conditions 347 fails, it sends a CDN to the remote PE to reject the connection 348 request. 350 The local PE can optionally include a result code in the CDN to 351 indicate the disconnect cause. The possible result codes are: 353 RC-TBA-1 - Attempt to connect to non-existent forwarder 354 RC-TBA-2 - Attempt to connect to unauthorized forwarder 356 5.2 Pseudowire Tie Detection 358 Conceivably in the network reference models, as either PE may 359 initiate a pseudowire to another PE at any time, the PEs could end up 360 initiating a pseudowire to each other simultaneously. In order to 361 avoid setting up duplicated pseudowires between two forwarders, each 362 PE must be able to independently detect such a pseudowire tie. The 363 following procedures need to be followed to detect a tie: 365 If both TAII and SAII are present in the ICRQ, the receiving PE 366 compares the TAII and SAII against the SAII and TAII itself 367 previously sent to the sending PE. If the received TAII matches the 368 sent SAII and the received SAII matches the sent TAII, a tie is 369 detected. 371 If only the TAII is present in the ICRQ, the SAII is assumed to have 372 the same value as the TAII. The receiving PE compares the received 373 TAII with the SAII that it previously sent to the sending PE. If the 374 SAII in that ICRQ is also omitted, then the value encoded in the sent 375 TAII is used for comparison. If they match, a tie is detected. 377 If the AGI is present, it is first prepended to the TAII and SAII 378 values before the tie detection occurs. 380 Once a tie has been discovered, the standard L2TP tie breaking 381 procedure is used to disconnect the duplicated pseudowire. 383 5.3 Generic Algorithm 385 The following uses a generic algorithm to illustrate the protocol 386 interactions when constructing an L2VPN using L2TP signaling. 388 Each PE first forms a list, SOURCE_FORWARDERS, consisting of all 389 local forwarders of a given VPN. Then it puts all local forwarders 390 that need to be interconnected and all remote forwarders of the same 391 VPN into another list, TARGET_FORWARDERS. The formation of the 392 network topology depends on the content in the SOURCE_FORWARDERS and 393 TARGET_FORWARDERS lists. These two lists can be constructed by 394 manual configuration and/or some auto-discovery procedure. 396 The algorithm is used to set up pseudowires among all the forwarders 397 that intend to be interconnected by iterating through each source and 398 target forwarder. An L2VPN is formed upon finishing the algorithm in 399 every participating PE of this L2VPN. 401 1. Pick the next forwarder, from SOURCE_FORWARDERS. If no 402 forwarder is available for processing, the processing is 403 complete. 405 2. Pick the next forwarder, from TARGET_FORWARDERS. If no 406 forwarder is available for processing, go back to step 1. 408 3. If the two forwarders are associated with different Router 409 IDs, a pseudowire must be established between them. Proceed 410 to step 6. 412 4. Compare the values of the two forwarders. If 413 they match, the source and target forwarders are the same, 414 so no more action is necessary. Go back to step 2. 416 5. As the source and target forwarders both reside on the local 417 PE, no pseudowire is needed. The PE simply creates a local 418 cross-connect between the two forwarders. Go back to step 2. 420 6. As the source and target forwarders reside on different PEs, 421 a pseudowire must be established between them. The PE first 422 examines if the source forwarder has already established a 423 pseudowire to the target forwarder. If so, go back to step 2. 425 7. If no pseudowire is already established between the source and 426 target forwarders, the local PE obtains the address of the 427 remote PE, and establishes a control connection to the remote 428 PE if one does not already exist. 430 8. The local PE sends an ICRQ to the remote PE. The AGI, TAII, 431 and SAII values are encoded in the AGI AVP, the Remote End ID 432 AVP, and the Local End ID AVP respectively. 434 9. If the local PE receives a response corresponding to the 435 ICRQ it just sent, proceed to step 10. Otherwise, if the 436 local PE receives an ICRQ from the same remote PE, proceed 437 to step 11. 439 10. The local PE receives a response from the remote PE. If 440 it is a CDN, go back to step 2. If it's an ICRP, the local 441 PE binds the source forwarder to the pseudowire and sends 442 an ICCN to the remote PE. Go back to step 2. 444 11. If the local PE receives an ICRQ from the same remote PE, 445 it needs to perform session tie detection, as described in 446 Section 5.2. If a session tie is detected, the PE performs 447 tie breaking. 449 12. If the local PE loses the tie breaker, it sends a CDN with 450 the result code that indicates the disconnection is due to 451 losing the tie breaker. Proceed to step 14. 453 13. If the local PE wins the tie breaker, it ignores the remote 454 PE's ICRQ, but acknowledges receipt of the control message 455 and continues waiting for the response from the remote PE. 456 Go to step 10. 458 14. The local PE determines whether it should accept the 459 connection request, as described in the Section 5.1. 460 If it accepts the ICRQ, it sends an ICRP to the remote PE. 462 15. The local PE receives a response from the remote PE. If 463 it is a CDN, go back to step 2. If it is an ICCN, the local 464 PE binds the source forwarder to the pseudowire, go back 465 to step 2. 467 The following diagram illustrates the above procedure: 469 ---------> Pick Next 470 | Source Forwarder 471 | | 472 | | 473 | v N 474 | Found Source Forwarder? ----------> End 475 | | 476 | Y | 477 | v 478 | Pick Next <-------------------------------- 479 | Target Forwarder | 480 | | | 481 | | | 482 | N v | 483 -------- Found Target Forwarder? | 484 | | 485 Y | | 486 v Y Y | 487 Same Router ID? ------> Same Forwarder ID? ------| 488 | | | 489 N | N | | 490 | v | 491 | Create Local -------| 492 v Cross-connect | 493 Pseudowire Already Y | 494 Established Between -------------------------------| 495 Source and Target? | 496 | | 497 N | | 498 v | 499 Local Initiates Pseudowire | 500 Connection Request to Remote | 501 | | 502 | | 503 v | 504 -------> Local Wait for Message | 505 | ----- from Remote -------------- | 506 | | | | 507 | | | | 508 | v v | 509 | Local Receives Pseudowire Local Receives Pseudowire | 510 | Connection Request Connection Response | 511 | from Remote from Remote | 512 | | | | 513 | | | | 514 | v v N | 515 | Perform Pseudowire Connection Accepted? --------| 516 | Tie Detection | | 517 | | Y | | 518 | | v | 519 | | Local Binds Source ---------| 520 | | Forwarder to Pseudowire | 521 | | | 522 | v N N | 523 | Tie Detected? -----> Accept Remote -----> Reject ------| 524 | | Connection Request? Remote Request | 525 | Y | ^ | | 526 | v | | Y | 527 | Perform Tie Breaking | ------> Local Binds ---- 528 | | | Source Forwarder 529 | | | to Pseudowire 530 | v N | 531 | Won Tie Breaking? ------> Disconnect 532 | | Local Connection 533 | Y | 534 | v 535 ------ Ignore Remote 536 Connection Request 538 6. IANA Considerations 540 This document defines three new L2TP control message Attribute Value 541 Pairs (AVPs) to be assigned by the IANA. These are described in 542 Section 4.3 are summarized below: 544 AVP-TBA-1 - Attachment Group Identifier 545 AVP-TBA-2 - Local End Identifier 546 AVP-TBA-3 - Interface Maximum Transmission Unit 548 Section 5.1 defines two new result codes for the CDN message are to 549 be assigned by the IANA: 551 RC-TBA-1 - Attempt to connect to non-existent forwarder 552 RC-TBA-2 - Attempt to connect to unauthorized forwarder 554 7. Security Considerations 556 The signaling procedures described in this document does not incur 557 additional security considerations that L2TP already provisions. 559 8. Intellectual Property Statement 561 The IETF takes no position regarding the validity or scope of any 562 Intellectual Property Rights or other rights that might be claimed to 563 pertain to the implementation or use of the technology described in 564 this document or the extent to which any license under such rights 565 might or might not be available; nor does it represent that it has 566 made any independent effort to identify any such rights. Information 567 on the procedures with respect to rights in RFC documents can be 568 found in BCP 78 and BCP 79. 570 Copies of IPR disclosures made to the IETF Secretariat and any 571 assurances of licenses to be made available, or the result of an 572 attempt made to obtain a general license or permission for the use of 573 such proprietary rights by implementers or users of this 574 specification can be obtained from the IETF on-line IPR repository at 575 http://www.ietf.org/ipr. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights that may cover technology that may be required to implement 580 this standard. Please address the information to the IETF at ietf- 581 ipr@ietf.org. 583 9. Full Copyright Statement 585 Copyright (C) The Internet Society (2004). This document is subject 586 to the rights, licenses and restrictions contained in BCP 78 and 587 except as set forth therein, the authors retain all their rights. 589 This document and the information contained herein are provided on an 590 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 591 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 592 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 593 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 594 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 595 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 597 10. Acknowledgement 599 The author would like to thank Mark Townsley and Carlos Pignataro for 600 their valuable input. 602 11. References 604 11.1 Normative References 606 [L2TPv3] J. Lau et. al., "Layer Two Tunneling Protocol (version3)", 607 draft-ietf-l2tpext-l2tp-base-14.txt, June 2004 609 11.2 Informative References 611 [L2VPN FW] L. Andersson et. al., "PPVPN L2 Framework", 612 draft-ietf-l2vpn-l2-framework-05.txt, June 2004 614 [PWE3L2TP] W. Townsley, "Pseudowires and L2TPv3", 615 draft-townsley-pwe3-l2tpv3-01.txt, June 2003 617 [RFC 2661] W. Townsley et. al., "Layer 2 Tunnel Protocol (L2TP)", 618 RFC 2661, August 1999. 620 12. Authors' Address 622 Wei Luo 623 Cisco Systems, Inc. 624 170 West Tasman Drive 625 San Jose, CA 95134 626 Email: luo@cisco.com