diff options
Diffstat (limited to 'doc/rfc/rfc4667.txt')
| -rw-r--r-- | doc/rfc/rfc4667.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc4667.txt b/doc/rfc/rfc4667.txt new file mode 100644 index 0000000..ef5128b --- /dev/null +++ b/doc/rfc/rfc4667.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group W. Luo +Request for Comments: 4667 Cisco Systems, Inc. +Category: Standards Track September 2006 + + + Layer 2 Virtual Private Network (L2VPN) Extensions + for Layer 2 Tunneling Protocol (L2TP) + + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + The Layer 2 Tunneling Protocol (L2TP) provides a standard method for + setting up and managing L2TP sessions to tunnel a variety of L2 + protocols. One of the reference models supported by L2TP describes + the use of an L2TP session to connect two Layer 2 circuits attached + to a pair of peering L2TP Access Concentrators (LACs), which is a + basic form of Layer 2 Virtual Private Network (L2VPN). This document + defines the protocol extensions for L2TP to set up different types of + L2VPNs in a unified fashion. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Specification of Requirements ..............................2 + 2. Network Reference Model .........................................2 + 3. Forwarder Identifier ............................................3 + 4. Protocol Components .............................................4 + 4.1. Control Messages ...........................................4 + 4.2. Existing AVPs for L2VPN ....................................4 + 4.3. New AVPs for L2VPN .........................................5 + 4.4. AVP Interoperability .......................................7 + 5. Signaling Procedures ............................................7 + 5.1. Overview ...................................................7 + 5.2. Pseudowire Tie Detection ...................................8 + 5.3. Generic Algorithm ..........................................9 + 6. IANA Considerations ............................................12 + + + +Luo Standards Track [Page 1] + +RFC 4667 L2VPN Extensions for L2TP September 2006 + + + 7. Security Considerations ........................................12 + 8. Acknowledgement ................................................13 + 9. References .....................................................13 + 9.1. Normative References ......................................13 + 9.2. Informative References ....................................13 + +1. Introduction + + [RFC3931] defines a dynamic tunneling mechanism to carry multiple + Layer 2 protocols besides Point-to-Point Protocol (PPP), the only + protocol supported in [RFC2661], over a packet-based network. The + baseline protocol supports various types of applications, which have + been highlighted in the different Layer 2 Tunneling Protocol (L2TP) + reference models in [RFC3931]. An L2TP Access Concentrator (LAC) is + an L2TP Control Connection Endpoint (LCCE) that cross-connects + attachment circuits and L2TP sessions. Layer 2 Virtual Private + Network (L2VPN) applications are typically in the scope of the LAC- + LAC reference model. + + This document discusses the commonalities and differences among L2VPN + applications with respect to using L2TPv3 as the signaling protocol. + In this document, the acronym "L2TP" refers to L2TPv3 or L2TP in + general. + +1.1. Specification of Requirements + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. Network Reference Model + + In the LAC-LAC reference model, a LAC serves as a cross-connect + between attachment circuits and L2TP sessions. Each L2TP session + acts as an emulated circuit, also known as pseudowire. A pseudowire + is used to bind two "forwarders" together. For different L2VPN + applications, different types of forwarders are defined. + + In the L2VPN framework [L2VPNFW], a LAC is a Provider Edge (PE) + device. LAC and PE are interchangeable terms in the context of this + document. Remote systems in the LAC-LAC reference model are Customer + Edge (CE) devices. + + + + + + + + + +Luo Standards Track [Page 2] + +RFC 4667 L2VPN Extensions for L2TP September 2006 + + + +----+ L2 +----+ +----+ L2 +----+ + | CE |------| PE |....[core network]....| PE |------| CE | + +----+ +----+ +----+ +----+ + + |<- emulated service ->| + |<----------------- L2 service -------------->| + + L2VPN Network Reference Model + + In a simple cross-connect application, an attachment circuit is a + forwarder directly bound to a pseudowire. It is a one-to-one + mapping. Traffic received from the attachment circuit on a local PE + is forwarded to the remote PE through the pseudowire. When the + remote PE receives traffic from the pseudowire, it forwards the + traffic to the corresponding attachment circuit on its end. The + forwarding decision is based on the attachment circuit or pseudowire + demultiplexing identifier. + + With Virtual Private LAN Service (VPLS), a Virtual Switching Instance + (VSI) is a forwarder connected to one or more attachment circuits and + pseudowires. A single pseudowire is used to connect a pair of VSIs + on two peering PEs. Traffic received from an attachment circuit or a + pseudowire is first forwarded to the corresponding VSI based on the + attachment circuit or pseudowire demultiplexing identifier. The VSI + performs additional lookup to determine where to further forward the + traffic. + + With Virtual Private Wire Service (VPWS), attachment circuits are + grouped into "colored pools". Each pool is a forwarder and is + connected through a network of point-to-point cross-connects. The + data forwarding perspective is identical to the cross-connect + application. However, constructing colored pools involves more + complicated signaling procedures. + +3. Forwarder Identifier + + A forwarder identifier is assigned to each forwarder on a given PE + and is unique in the context of the PE. It is defined as the + concatenation of an Attachment Group Identifier (AGI) and an + Attachment Individual Identifier (AII), denoted as <AGI, AII>. The + AGI is used to group a set of forwarders together for signaling + purposes. An AII is used to distinguish forwarders within a group. + AII can be unique on a per-platform or per-group basis. + + As far as the signaling procedures are concerned, a forwarder + identifier is an arbitrary string of bytes. It is up to + implementations to decide the values for AGI and AII. + + + + +Luo Standards Track [Page 3] + +RFC 4667 L2VPN Extensions for L2TP September 2006 + + + When connecting two forwarders together, both MUST have the same AGI + as part of their forwarder identifiers. The AII of the source + forwarder is known as the Source AII (SAII), and the AII of the + target forwarder is known as the Target AII (TAII). Therefore, the + source forwarder and target forwarder can be denoted as <AGI, SAII> + and <AGI, TAII>, respectively. + +4. Protocol Components + +4.1. Control Messages + + L2TP defines two sets of session management procedures: incoming call + and outgoing call. Even though it is entirely possible to use the + outgoing call procedures for signaling L2VPNs, the incoming call + procedures have some advantages in terms of the relevance of the + semantics. [PWE3L2TP] gives more details on why the incoming call + procedures are more appropriate for setting up pseudowires. + + The signaling procedures for L2VPNs described in the following + sections are based on the Control Connection Management and the + Incoming Call procedures, defined in Sections 3.3 and 3.4.1 of + [RFC3931], respectively. L2TP control message types are defined in + Section 3.1 of [RFC3931]. This document references the following + L2TP control messages: + + Start-Control-Connection-Request (SCCRQ) + Start-Control-Connection-Reply (SCCRP) + Incoming-Call-Request (ICRQ) + Incoming-Call-Reply (ICRP) + Incoming-Call-Connected (ICCN) + Set-Link-Info (SLI) + +4.2. Existing AVPs for L2VPN + + The following Attribute Value Pairs (AVPs), defined in Sections + 5.4.3, 5.4.4, and 5.4.5 of [RFC3931], are used for signaling L2VPNs. + + Router ID + + The Router ID sent in SCCRQ and SCCRP during control connection + setup establishes the unique identity of each PE. + + Pseudowire Capabilities List + + The Pseudowire Capabilities List sent in the SCCRQ and SCCRP + indicates the pseudowire types supported by the sending PE. It + merely serves as an advertisement to the receiving PE. Its + content should not affect the control connection setup. + + + +Luo Standards Track [Page 4] + +RFC 4667 L2VPN Extensions for L2TP September 2006 + + + Before a local PE initiates a session of a particular pseudowire + type to a remote PE, it MUST examine whether the remote PE has + advertised this pseudowire type in this AVP and SHOULD NOT attempt + to initiate the session if the intended pseudowire type is not + supported by the remote PE. + + Pseudowire Type + + The Pseudowire Type sent in ICRQ signals the intended pseudowire + type to the receiving PE. The receiving PE checks it against its + local pseudowire capabilities list. If it finds a match, it + responds with an ICRP without a Pseudowire Type AVP, which + implicitly acknowledges its acceptance of the intended pseudowire. + If it does not find a match, it MUST respond with a Call- + Disconnect-Notify (CDN), with an "unsupported pseudowire type" + result code. + + L2-Specific Sublayer + + The L2-Specific Sublayer can be sent in ICRQ, ICRP, and ICCN. If + the receiving PE supports the specified L2-Specific Sublayer, it + MUST include the identified L2-Specific Sublayer in its data + packets sent to the sending PE. Otherwise, it MUST reject the + connection by sending a CDN to the sending PE. + + Circuit Status + + The Circuit Status is sent in both ICRQ and ICRP to inform the + receiving PE about the circuit status on the sending PE. It can + also be sent in ICCN and SLI to update the status. + + Remote End Identifier + + The TAII value is encoded in the Remote End ID AVP and sent in + ICRQ along with the optional AGI to instruct the receiving PE to + bind the proposed pseudowire to the forwarder that matches the + specified forwarder identifier. + +4.3. New AVPs for L2VPN + + Attachment Group Identifier + + The AGI AVP, Attribute Type 89, is an identifier used to associate + a forwarder to a logical group. The AGI AVP is used in + conjunction with the Local End ID AVP and Remote End ID AVP, which + encode the SAII and TAII, respectively, to identify a specific + forwarder. When the AGI AVP is omitted in the control messages or + contains a zero-length value, the forwarders are considered to use + + + +Luo Standards Track [Page 5] + +RFC 4667 L2VPN Extensions for L2TP September 2006 + + + the default AGI. Note that there is only one designated default + AGI value for all forwarders. + + The Attribute Value field for this AVP has the following format: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|H|0|0|0|0| Length | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 89 | AGI (variable length) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The AGI field is a variable-length field. This AVP MAY be present + in ICRQ. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The hiding of + AVP attribute values is defined in Section 5.3 of [RFC3931]. The + M bit for this AVP SHOULD be set to 0. The Length (before hiding) + of this AVP is 6 octets plus the length of the AGI field. + + Local End ID + + The Local End ID AVP, Attribute Type 90, encodes the SAII value. + The SAII may also be used in conjunction with the TAII to detect + pseudowire ties. When it is omitted in the control messages, it + is assumed that it has the same value as the TAII. + + The Attribute Value field for this AVP has the following format: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|H|0|0|0|0| Length | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 90 | SAII (variable length) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The SAII field is a variable-length field. This AVP MAY be + present in ICRQ. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 0. The Length (before hiding) of this + AVP is 6 octets plus the length of the SAII field. + + Interface Maximum Transmission Unit + + The Interface Maximum Transmission Unit (MTU) AVP, Attribute Type + + + +Luo Standards Track [Page 6] + +RFC 4667 L2VPN Extensions for L2TP September 2006 + + + 91, indicates the MTU in octets of a packet that can be sent out + from the CE-facing interface. The MTU values of a given + pseudowire, if advertised in both directions, MUST be identical. + If they do not match, the pseudowire SHOULD NOT be established. + When this AVP is omitted in the control messages in either + direction, it is assumed that the remote PE has the same interface + MTU as the local PE for the pseudowire being signaled. + + The Attribute Value field for this AVP has the following format: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|H|0|0|0|0| Length | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 91 | Interface MTU | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Interface MTU field is a 2-octet integer value. This AVP MAY + be present in ICRQ and ICRP. When a PE receives an Interface MTU + AVP with an MTU value different from its own, it MAY respond with + a CDN with a new result code indicating the disconnect cause. + + 23 - Mismatching interface MTU + + This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for + this AVP SHOULD be set to 0. The Length (before hiding) of this + AVP is 8 octets. + +4.4. AVP Interoperability + + To ensure interoperability, the mandatory (M) bit settings of the + existing AVPs used in L2VPN applications should be the same as those + specified in [RFC3931]. The generic M-bit processing is described in + Section 5.2 of [RFC3931]. Setting the M-bit of the new AVPs to 1 + will impair interoperability. + +5. Signaling Procedures + +5.1. Overview + + Assume that a PE assigns a forwarder identifier to one of its local + forwarders and that it knows it needs to set up a pseudowire to a + remote forwarder on a remote PE that has a certain Forwarder ID. + This knowledge can be obtained either through manual configuration or + some auto-discovery procedure. + + Before establishing the intended pseudowire, each pair of peering PEs + + + +Luo Standards Track [Page 7] + +RFC 4667 L2VPN Extensions for L2TP September 2006 + + + exchanges control connection messages to establish a control + connection. Each advertises its supported pseudowire types, as + defined in [PWE3IANA], in the Pseudowire Capabilities List AVP. + + After the control connection is established, the local PE examines + whether the remote PE supports the pseudowire type it intends to set + up. Only if the remote PE supports the intended pseudowire type + should it initiate a pseudowire connection request. + + When the local PE receives an ICRQ for a pseudowire connection, it + examines the forwarder identifiers encoded in the AGI, SAII, and TAII + in order to determine the following: + + - Whether it has a local forwarder with the forwarder identifier + value specified in the ICRQ. + + - Whether the remote forwarder with the forwarder identifier + specified in the ICRQ is allowed to connect with this local + forwarder. + + If both conditions are met, it sends an ICRP to the remote PE to + accept the connection request. If either of the two conditions + fails, it sends a CDN to the remote PE to reject the connection + request. + + The local PE can optionally include a result code in the CDN to + indicate the disconnect cause. The possible result codes are + + 24 - Attempt to connect to non-existent forwarder + 25 - Attempt to connect to unauthorized forwarder + +5.2. Pseudowire Tie Detection + + Conceivably in the network reference models, as either PE may + initiate a pseudowire to another PE at any time, the PEs could end up + initiating a pseudowire to each other simultaneously. In order to + avoid setting up duplicated pseudowires between two forwarders, each + PE must be able to independently detect such a pseudowire tie. The + following procedures need to be followed to detect a tie: + + If both TAII and SAII are present in the ICRQ, the receiving PE + compares the TAII and SAII against the SAII and TAII previously sent + to the sending PE. If the received TAII matches the sent SAII and + the received SAII matches the sent TAII, a tie is detected. + + If only the TAII is present in the ICRQ, the SAII is assumed to have + the same value as the TAII. The receiving PE compares the received + TAII with the SAII that it previously sent to the sending PE. If the + + + +Luo Standards Track [Page 8] + +RFC 4667 L2VPN Extensions for L2TP September 2006 + + + SAII in that ICRQ is also omitted, then the value encoded in the sent + TAII is used for comparison. If they match, a tie is detected. + + If the AGI is present, it is first prepended to the TAII and SAII + values before the tie detection occurs. + + Once a tie is discovered, the PE uses the standard L2TP tie breaking + procedure, as described in Section 5.4.4 of [RFC3931], to disconnect + the duplicated pseudowire. + +5.3. Generic Algorithm + + The following uses a generic algorithm to illustrate the protocol + interactions when constructing an L2VPN using L2TP signaling. + + Each PE first forms a list, SOURCE_FORWARDERS, consisting of all + local forwarders of a given VPN. Then it puts all local forwarders + that need to be interconnected and all remote forwarders of the same + VPN into another list, TARGET_FORWARDERS. The formation of the + network topology depends on the content in the SOURCE_FORWARDERS and + TARGET_FORWARDERS lists. These two lists can be constructed by + manual configuration or some auto-discovery procedure. + + The algorithm is used to set up a full mesh of interconnections + between SOURCE_FORWARDERS and TARGET_FORWARDERS. An L2VPN is formed + when the algorithm is finished in every participating PE of this + L2VPN. + + 1. Pick the next forwarder, from SOURCE_FORWARDERS. If no + forwarder is available for processing, the processing is + complete. + + 2. Pick the next forwarder, from TARGET_FORWARDERS. If no + forwarder is available for processing, go back to step 1. + + 3. If the two forwarders are associated with different Router + IDs, a pseudowire must be established between them. Proceed + to step 6. + + 4. Compare the <AGI, AII> values of the two forwarders. If + they match, the source and target forwarders are the same, + so no more action is necessary. Go back to step 2. + + 5. As the source and target forwarders both reside on the local + PE, no pseudowire is needed. The PE simply creates a local + cross-connect between the two forwarders. Go back to step 2. + + 6. As the source and target forwarders reside on different PEs, + + + +Luo Standards Track [Page 9] + +RFC 4667 L2VPN Extensions for L2TP September 2006 + + + a pseudowire must be established between them. The PE first + examines whether the source forwarder has already established a + pseudowire to the target forwarder. If so, go back to step 2. + + 7. If no pseudowire is already established between the source and + target forwarders, the local PE obtains the address of the + remote PE and establishes a control connection to the remote + PE if one does not already exist. + + 8. The local PE sends an ICRQ to the remote PE. The AGI, TAII, + and SAII values are encoded in the AGI AVP, the Remote End ID + AVP, and the Local End ID AVP, respectively. + + 9. If the local PE receives a response corresponding to the + ICRQ it just sent, proceed to step 10. Otherwise, if the + local PE receives an ICRQ from the same remote PE, proceed + to step 11. + + 10. The local PE receives a response from the remote PE. If + it is a CDN, go back to step 2. If it's an ICRP, the local + PE binds the source forwarder to the pseudowire and sends + an ICCN to the remote PE. Go back to step 2. + + 11. If the local PE receives an ICRQ from the same remote PE, + it needs to perform session tie detection, as described in + Section 5.2. If a session tie is detected, the PE performs + tie breaking. + + 12. If the local PE loses the tie breaker, it sends a CDN with + the result code that indicates that the disconnection is due to + losing the tie breaker. Proceed to step 14. + + 13. If the local PE wins the tie breaker, it ignores the remote + PE's ICRQ, but acknowledges receipt of the control message + and continues waiting for the response from the remote PE. + Go to step 10. + + 14. The local PE determines whether it should accept the + connection request, as described in Section 5.1. + If it accepts the ICRQ, it sends an ICRP to the remote PE. + + 15. The local PE receives a response from the remote PE. If + it is a CDN, go back to step 2. If it is an ICCN, the local + PE binds the source forwarder to the pseudowire, go back + to step 2. + + The following diagram illustrates the above procedure: + + + + +Luo Standards Track [Page 10] + +RFC 4667 L2VPN Extensions for L2TP September 2006 + + + ---------> Pick Next + | Source Forwarder + | | + | | + | v N + | Found Source Forwarder? ----------> End + | | + | Y | + | v + | Pick Next <-------------------------------- + | Target Forwarder | + | | | + | | | + | N v | + -------- Found Target Forwarder? | + | | + Y | | + v Y Y | + Same Router ID? ------> Same Forwarder ID? ------| + | | | + N | N | | + | v | + | Create Local -------| + v Cross-connect | + Pseudowire Already Y | + Established Between -------------------------------| + Source and Target? | + | | + N | | + v | + Local Initiates Pseudowire | + Connection Request to Remote | + | | + | | + v | + -------> Local Wait for Message | + | ----- from Remote -------------- | + | | | | + | | | | + | v v | + | Local Receives Pseudowire Local Receives Pseudowire | + | Connection Request Connection Response | + | from Remote from Remote | + | | | | + | | | | + | v v N | + | Perform Pseudowire Connection Accepted? --------| + | Tie Detection | | + + + +Luo Standards Track [Page 11] + +RFC 4667 L2VPN Extensions for L2TP September 2006 + + + | | Y | | + | | v | + | | Local Binds Source ---------| + | | Forwarder to Pseudowire | + | | | + | v N N | + | Tie Detected? -----> Accept Remote -----> Reject ------| + | | Connection Request? Remote Request | + | Y | ^ | | + | v | | Y | + | Perform Tie Breaking | ------> Local Binds ---- + | | | Source Forwarder + | | | to Pseudowire + | v N | + | Won Tie Breaking? ------> Disconnect + | | Local Connection + | Y | + | v + ------ Ignore Remote + Connection Request + +6. IANA Considerations + + The IANA registry procedure in this document follows that in Section + 10 of [RFC3931]. The IANA has assigned the following new values for + existing registries managed by IANA. + + This document defines three new L2TP control message Attribute Value + Pairs (AVPs) that have been assigned by the IANA. These are + described in Section 4.3 and are summarized below: + + 89 - Attachment Group Identifier + 90 - Local End Identifier + 91 - Interface Maximum Transmission Unit + + Sections 4.3 and 5.1 define three new result codes for the CDN + message that have been assigned by the IANA: + + 23 - Mismatching interface MTU + 24 - Attempt to connect to non-existent forwarder + 25 - Attempt to connect to unauthorized forwarder + +7. Security Considerations + + This specification does not introduce any additional security + considerations beyond those discussed in [RFC3931] and [L2VPNFW]. + + + + + +Luo Standards Track [Page 12] + +RFC 4667 L2VPN Extensions for L2TP September 2006 + + +8. Acknowledgement + + The author would like to thank Mark Townsley and Carlos Pignataro for + their valuable input. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling + Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. + +9.2. Informative References + + [PWE3IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge + Emulation (PWE3)", BCP 116, RFC 4446, April 2006. + + [L2VPNFW] Andersson L., Ed. and E. Rosen, Ed., "Framework for Layer + 2 Virtual Private Networks (L2VPNs)", RFC 4664, September + 2006. + + [PWE3L2TP] W. Townsley, "Pseudowires and L2TPv3", Work in Progress. + + [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, + G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", + RFC 2661, August 1999. + +Author's Address + + Wei Luo + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134 + + EMail: luo@cisco.com + + + + + + + + + + + + + +Luo Standards Track [Page 13] + +RFC 4667 L2VPN Extensions for L2TP September 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Luo Standards Track [Page 14] + |