diff options
author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
---|---|---|
committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc3355.txt | |
parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc3355.txt')
-rw-r--r-- | doc/rfc/rfc3355.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc3355.txt b/doc/rfc/rfc3355.txt new file mode 100644 index 0000000..5b2afec --- /dev/null +++ b/doc/rfc/rfc3355.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group A. Singh +Request for Comments: 3355 Motorola +Category: Standards Track R. Turner + Paradyne + R. Tio + S. Nanji + Redback Networks + August 2002 + + + Layer Two Tunnelling Protocol (L2TP) + Over ATM Adaptation Layer 5 (AAL5) + +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 (2002). All Rights Reserved. + +Abstract + + The Layer Two Tunneling Protocol (L2TP) provides a standard method + for transporting the link layer of the Point-to-Point Protocol (PPP) + between a dial-up server and a Network Access Server, using a network + connection in lieu of a physical point-to-point connection. This + document describes the use of an Asynchronous Transfer Mode (ATM) + network for the underlying network connection. ATM User-Network + Interface (UNI) Signaling Specification Version 4.0 or Version 3.1 + with ATM Adaptation Layer 5 (AAL5) are supported as interfaces to the + ATM network. + +Applicability + + This specification is intended for implementations of L2TP that use + ATM to provide the communications link between the L2TP Access + Concentrator and the L2TP Network Server. + + + + + + + + + +Singh, et. al. Standards Track [Page 1] + +RFC 3355 L2TP Over AAL5 August 2002 + + +1. Introduction + + The Point-to-Point Protocol (PPP) [RFC1661], is frequently used on + the link between a personal computer with a dial modem and a network + service provider, or NSP. The Layer Two Tunneling Protocol (L2TP) + [RFC2661] enables a dial-up server to provide access to a remote NSP + by extending the PPP connection through a tunnel in a network to + which both it and the NSP are directly connected. A "tunnel" is a + network layer connection between two nodes, used in the role of a + data link layer connection between those nodes, possibly as part of a + different network. In [RFC2661] the dial-up server is called an L2TP + Access Concentrator, or LAC. The remote device that provides access + to a network is called an L2TP Network Server, or LNS. L2TP uses a + packet delivery service to create a tunnel between the LAC and the + LNS. "L2TP is designed to be largely insulated from the details of + the media over which the tunnel is established; L2TP requires only + that the tunnel media provide packet oriented point-to-point + connectivity" [RFC2661]. An ATM network with AAL5 offers a suitable + form of packet oriented connection. This standard supplements + [RFC2661] by providing details specific to the use of AAL5 for a + point-to-point connection between LAC and LNS. + +2. Conventions + + Requirements keywords 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]. + + A list of acronyms used in this document is given at the end of the + document as Appendix A. + +3. AAL5 Layer Service Interface + + L2TP treats the underlying ATM AAL5 layer service as a bit- + synchronous point-to-point link. In this context, the L2TP link + corresponds to an ATM AAL5 virtual circuit (VC). The VC MUST be + full-duplex, point to point, and it MAY be either dedicated (i.e., + permanent, set up by provisioning) or switched (set up on demand.) + + The AAL5 message mode service, in the non-assured mode of operation, + without the corrupted delivery option MUST be used. + + Interface Format - The L2TP/AAL5 layer boundary presents an octet + service interface to the AAL5 layer. There is no provision for sub- + octets to be supplied or accepted. + + + + + +Singh, et. al. Standards Track [Page 2] + +RFC 3355 L2TP Over AAL5 August 2002 + + +3.1 Maximum Transfer Unit + + Each L2TP PDU MUST be transported within a single AAL5 PDU. + Therefore the maximum transfer unit (MTU) of the AAL5 connection + constrains the MTU of the L2TP tunnel that uses the connection and + the MTU of all PPP connections that use the tunnel. ([RFC1661] + refers to this as Maximum Receive Unit, or MRU. In [SIG31], it is + the Forward and Backward Maximum CPCS-SDU Size.) + + An implementation MUST support a PPP MRU of at least 1500 bytes. + + An implementation SHOULD use a larger MTU than the minimum value + specified above. It is RECOMMENDED that an implementation support an + IP packet of at least 9180 bytes in the PPP PDU. + +3.2 Quality of Service + + In order to provide a desired Quality of Service (QoS), and possibly + different qualities of service to different client connections, an + implementation MAY use more than one AAL5 connection between LAC and + LNS. + + QoS mechanisms, such as Differentiated UBR [DUBR], that could involve + inverse multiplexing a tunnel across multiple VCs are for further + study. QoS mechanisms applicable to a single tunnel corresponding to + a single VC, are independent of the ATM transport and out of scope of + this document. + +3.3 ATM Connection Parameters + + The L2TP layer does not impose any restrictions regarding + transmission rate or the underlying ATM layer traffic descriptor + parameters. + + Specific traffic parameters MAY be set for a PVC connection by + agreement between the communicating parties. The caller MAY request + specific traffic parameters at the time an SVC connection is set up. + + Autoconfiguration of end-systems for PVCs can be facilitated by the + use of the optional ILMI 4.0 extensions documented in [ILMIA]. This + provides comparable information to the IEs used for control plane + connection establishment. + + + + + + + + + +Singh, et. al. Standards Track [Page 3] + +RFC 3355 L2TP Over AAL5 August 2002 + + +4. Multi-Protocol Encapsulation + + This specification uses the principles, terminology, and frame + structure described in "Multiprotocol Encapsulation over ATM + Adaptation Layer 5" [RFC2684]. The purpose of this specification is + not to reiterate what is already standardized in [RFC2684], but to + specify how the mechanisms described in [RFC2684] are to be used to + map L2TP onto an AAL5-based ATM network. + + As specified in [RFC2684], L2TP PDUs shall be carried in the payload + field of Common Part Convergence Sublayer (CPCS) PDUs of AAL5, and + the Service Specific Convergence Sublayer (SSCS) of AAL5 shall be + empty. + + Section 1 of [RFC2684] defines two mechanisms for identifying the + protocol encapsulated in the AAL5 PDU's payload field: + + 1. Virtual circuit (VC) based multiplexing. + 2. Logical Link Control (LLC) encapsulation. + + In the first mechanism, the payload's protocol type is implicitly + agreed to by the end points for each virtual circuit using + provisioning or control plane procedures. This mechanism will be + referred to as "VC-multiplexed L2TP". + + In the second mechanism, the payload's protocol type is explicitly + identified in each AAL5 PDU by an IEEE 802.2 LLC header. This + mechanism will be referred to as "LLC encapsulated L2TP". + + An L2TP implementation: + + 1. MUST support LLC encapsulated L2TP on PVCs. + 2. MAY support LLC encapsulated L2TP on SVCs. + 3. MAY support VC-multiplexed L2TP on PVCs or SVCs. + + When a PVC is used, the endpoints must be configured to use one of + the two encapsulation methods. + + If an implementation supports SVCs, it MUST use the [Q.2931] Annex C + procedure to negotiate connection setup, encoding the Broadband Lower + Layer Interface (B-LLI) information element (IE) to signal either + VC-multiplexed L2TP or LLC encapsulated L2TP. The details of this + control plane procedure are described in section 7. + + If an implementation is connecting through a Frame Relay/ATM FRF.8 + [FRF8] service inter-working unit, then it MUST use LLC encapsulated + L2TP. + + + + +Singh, et. al. Standards Track [Page 4] + +RFC 3355 L2TP Over AAL5 August 2002 + + +5. LLC Encapsulated L2TP over AAL5 + + When LLC encapsulation is used, the payload field of the AAL5 CPCS + PDU SHALL be encoded as shown in Figure 1. The pertinent fields in + that diagram are: + + 1. IEEE 802.2 LLC header: Source and destination SAP of 0xAA + followed by a frame type of Un-numbered Information (value + 0x03). This LLC header indicates that an IEEE 802.1a SNAP + header follows [RFC2684]. + + 2. IEEE 802.1a SNAP Header: The three octet Organizationally + Unique Identifier (OUI) value of 0x00-00-5E identifies IANA + (Internet Assigned Numbers Authority.) The two octets Protocol + Identifier (PID) identifies L2TP as the encapsulated protocol. + The PID value is 0x0007. + + 3. The L2TP PDU: + + Figure 1 - LLC Encapsulated L2TP PDU + + +-------------------------+ -------- + | Destination SAP (0xAA) | ^ + +-------------------------+ | + | Source SAP (0xAA) | LLC header + +-------------------------+ | + | Frame Type = UI (0x03) | V + +-------------------------+ -------- + | OUI (0x00-00-5E)| | + +-+-+-+-+-+-+-+-+-+-+-+-+-| SNAP Header + | PID (0x00-07) | | + +-------------------------+ -------- + | | | + | | L2TP PDU + | | | + +-------------------------+ -------- + + Note: The format of the overall AAL5 CPCS PDU is shown in the next + section. + + The end points MAY be bi-laterally provisioned to send other LLC- + encapsulated protocols besides L2TP across the same virtual + connection. + + + + + + + + +Singh, et. al. Standards Track [Page 5] + +RFC 3355 L2TP Over AAL5 August 2002 + + +6. Virtual Circuit Multiplexed L2TP over AAL5 + + VC-multiplexed L2TP over AAL5 is an alternative technique to LLC + encapsulated L2TP over AAL5. In this case, the L2TP PDU is the AAL5 + payload without an LLC header. This is sometimes called "Null + encapsulation." + + Figure 2 - AAL5 CPCS-PDU Format + + +-------------------------------+ ------- + | . | ^ + | . | | + | CPCS-PDU payload | L2TP PDU + | up to 2^16 - 1 octets) | | + | . | V + +-------------------------------+ ------- + | PAD ( 0 - 47 octets) | + +-------------------------------+ ------- + | CPCS-UU (1 octet ) | ^ + +-------------------------------+ | + | CPI (1 octet ) | | + +-------------------------------+CPCS-PDU Trailer + | Length (2 octets) | | + +-------------------------------| | + | CRC (4 octets) | V + +-------------------------------+ ------- + + The Common Part Convergence Sub-layer (CPCS) PDU payload field + contains user information up to 2^16 - 1 octets. + + The PAD field pads the CPCS-PDU to fit exactly into the ATM cells + such that the last 48 octet cell payload created by the SAR sublayer + will have the CPCS-PDU Trailer right justified in the cell. + + The CPCS-UU (User-to-User indication) field is used to transparently + transfer CPCS user to user information. The field has no function + under the multi-protocol ATM encapsulation and MAY be set to any + value. + + The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to + 64 bits. Possible additional functions are for further study in + ITU-T. When only the 64 bit alignment function is used, this field + SHALL be coded as 0x00. + + The Length field indicates the length, in octets, of the payload + field. The maximum value for the Length field is 65535 octets. A + Length field coded as 0x00 MAY be used for the abort function. + + + + +Singh, et. al. Standards Track [Page 6] + +RFC 3355 L2TP Over AAL5 August 2002 + + + The CRC field is computed over the entire CPCS-PDU except the CRC + field itself. + + The CPCS-PDU payload SHALL consist of an L2TP PDU as defined in + [RFC2661]. + +7. Out-of-Band Control Plane Signaling + +7.1 Connection Setup + + An SVC connection can originate at either the LAC or the LNS. An + implementation that supports the use of SVCs MUST be able to both + originate and respond to SVC setup requests. Except for the B-LLI IE + specified below, all other IEs required for ATM User-Network + Interface (UNI) Signaling Specification Version 4.0 [SIG40] should be + encoded as per [RFC2331]. + + When originating an SVC AAL5 connection, the caller MUST request in + the SETUP message either VC-multiplexed L2TP, LLC encapsulated L2TP, + or both VC-multiplexed and LLC-encapsulated L2TP. The B-LLI IE SHALL + be used to specify the requested encapsulation method. When a caller + is offering both encapsulations, the two B-LLI IEs SHALL be encoded + within a Broadband Repeat Indicator information element in the order + of the sender's preference. + + An implementation MUST be able to accept an incoming call that offers + LLC encapsulated L2TP in the caller's request. The called peer's + implementation MUST reject a call setup request that only offers an + encapsulation that it does not support. Implementations originating + a call offering both protocol encapsulation techniques MUST be able + to accept the use of either encapsulation techniques. + + When originating an LLC encapsulated call that is to carry an L2TP + payload, the [Q.2931] B-LLI IE user information layer 2 protocol + field SHALL be encoded to select LAN Logical Link Control + (ISO/IEC8802-2) in octet 6. See [RFC2331] Appendix A for an example. + + When originating a VC-multiplexed call that is to carry an L2TP + payload, the [Q.2931] B-LLI IE user information layer 2 protocol + field SHALL be encoded to select no layer 2 protocol in octet 6 and + layer 3 protocol field SHALL be encoded to select ISO/IEC TR 9577 + [ISO9577] in octet 7. Furthermore, as per DSL Forum TR-037 + [DSLF037], the extension octets specify VC-multiplexed L2TP by using + the SNAP IPI, followed by an OUI owned by IANA, followed by the PID + assigned by IANA for L2TP. Thus, the User Information layer 3 + protocol field is encoded: 0B 80 00 00 5E 00 07. The AAL5 frame's + + + + + +Singh, et. al. Standards Track [Page 7] + +RFC 3355 L2TP Over AAL5 August 2002 + + + payload field will always contain an L2TP PDU. The SNAP IPI is + employed only to use the IANA L2TP protocol value to specify the VC- + multiplexed PDU. + + If the caller offers both encapsulation methods and the called peer + accepts the call, the called peer SHALL specify the encapsulation + method by including exactly one B-LLI IE in the Connect message. + + If an SVC tunnel is reset in accordance with section 4.1 of + [RFC2661], both ends MUST clear the SVC. Any user sessions on the + tunnel will be terminated by the reset. Either end MAY attempt to + re-establish the tunnel upon receipt of a new request from a client. + +7.2 Connection Setup Failure + + When a connection setup fails, the L2TP entity that attempted the + connection setup MAY consider the called entity unreachable until + notified that the unreachable entity is available. The conditions + under which an entity determines that another is unreachable and how + it determines that the other is available again are implementation + decisions. + +7.3 Connection Teardown + + When there are no active sessions on an SVC tunnel, either end MAY + optionally clear the connection. + +8. Connection Failure + + Upon notification that an AAL5 SVC connection has been cleared, an + Implementation SHALL tear down the tunnel and return the control + connection to the idle state. + +9. Security Considerations + + The Layer Two Tunneling Protocol base specification [RFC2661] + discusses basic security issues regarding L2TP tunneling. It is + possible that the L2TP over AAL5 tunnel security may be compromised + by the attack of ATM transport network itself. The ATM Forum has + published a security framework [AFSEC1] and a security specification + [AFSEC2] that define procedures to guard against common threats to an + ATM transport network. Applications that require protection against + threats to an ATM switching network are encouraged to use + authentication headers, or encrypted payloads, and/or the ATM-layer + security services described in [AFSEC2]. + + + + + + +Singh, et. al. Standards Track [Page 8] + +RFC 3355 L2TP Over AAL5 August 2002 + + +10. Acknowledgments + + This document draws heavily on material from: "PPP Over AAL5" (RFC + 2364) by George Gross, Manu Kaycee, Arthur Lin, Andrew Malis, and + John Stephens and an earlier document of L2TP over AAL5 by Nagraj + Arunkumar, Manu Kaycee, Tim Kwok, and Arthur Lin. + + Special thanks to Mike Davison, Arthur Lin, John Stevens for making + significant contributions to the initial version of this document. + + Special thanks to David Allan of Nortel for his invaluable review of + this document. + + The security section of this document is based upon RFC 3337, "Class + Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2 + (AAL2)", by Bruce Thompson, Bruce Buffam and Thima Koren. + +11. References + + [RFC2661] Townsley, W., Valencia, A., Rubens, A., Singh Pall, G., + Zorn, G. and B. Palter, "Layer Two Tunneling Protocol + (L2TP)", RFC 2661, August 1999. + + [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", + STD 51, RFC 1661, July 1994. + + [SIG31] The ATM Forum, "ATM User-Network Interface Specification + V3.1", af-uni-0010.002, 1994. + + [ITU93] International Telecommunication Union, "B-ISDN ATM + Adaptation Layer (AAL) Specification", ITU-T Recommendation + I.363, March 1993. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation + over ATM Adaptation Layer 5", RFC 2684, September 1999. + + [Q.2931] International Telecommunication Union, "Broadband + Integrated Service Digital Network (B-ISDN) Digital + Subscriber Signaling System No.2 (DSS2) User Network + Interface Layer 3 Specification for Basic Call/Connection + Control", ITU-T Recommendation Q.2931, Feb. 1995. + + [FRF8] The Frame Relay Forum, "Frame Relay/ATM PVC Service + Interworking Implementation Agreement", FRF.8, April 1995. + + + + +Singh, et. al. Standards Track [Page 9] + +RFC 3355 L2TP Over AAL5 August 2002 + + + [ISO9577] ISO/IEC DTR 9577.2, "Information technology - + Telecommunications and Information exchange between systems + - Protocol Identification in the network layer", 1995-08- + 16. + + [RFC2331] Maher, M., "ATM Signaling Support for IP over ATM - UNI + Signaling 4.0 Update", RFC 2331, April 1998. + + [DSLF037] DSL Forum Technical Report TR-037, "Auto-Configuration for + the Connection Between the DSL Broadband Network + Termination (B-NT) and the Network using ATM", March 2001. + + [SIG40] ATM Forum, "ATM User-Network Interface (UNI) Signaling + Specification Version 4.0", af-sig-0061.000, finalized July + 1996; available at ftp://ftp.atmforum.com/pub. + + [DUBR] ATM Forum, "Addendum to TM 4.1: Differentiated UBR", af- + tm-0149.000, finalized July, 2000; available at + ftp://ftp.atmforum.com/pub + + [ILMIA] ATM Forum, "Addendum to the ILMI Auto-configuration + extension", af-nm-00165.000, April 2001. + + [AFSEC1] The ATM Forum, "ATM Security Framework Version 1.0", af- + sec-0096.000, February 1998 + + [AFSEC2] The ATM Forum, "ATM Security Specification v1.1", af-sec- + 0100.002, March 2001 + + + + + + + + + + + + + + + + + + + + + + + +Singh, et. al. Standards Track [Page 10] + +RFC 3355 L2TP Over AAL5 August 2002 + + +Appendix A. Acronyms + + AAL5 ATM Adaptation Layer Type 5 + + ATM Asynchronous Transfer Mode + + B-LLI Broadband Low Layer Information + + CPCS Common Part Convergence Sublayer + + IANA Internet Assigned Numbers Authority + + IE Information Element + + L2TP Layer Two Tunneling Protocol + + LAC L2TP Access Concentrator + + LLC Logical Link Control + + LNS L2TP Network Server + + MTU Maximum Transfer Unit + + MRU Maximum Receive Unit + + NSP Network Service Provider + + OUI Organizationally Unique Identifier + + PDU Protocol Data Unit + + PID Protocol Identifier + + PPP Point-to-Point Protocol + + PVC Permanent Virtual Circuit + + SAP Service Access Point + + SNAP Subnetwork Address Protocol + + SVC Switched Virtual Circuit + + VC Virtual Circuit + + + + + + +Singh, et. al. Standards Track [Page 11] + +RFC 3355 L2TP Over AAL5 August 2002 + + +Authors' Addresses + + Rollins Turner + Paradyne Corporation + 8545 126th Avenue North + Largo, FL 33773 + + EMail: rturner@eng.paradyne.com + + + Rene Tio + Redback Networks, Inc. + 300 Holger Way + San Jose, CA 95134 + + EMail: tor@redback.com + + + Ajoy Singh + Motorola + 1421 West Shure Dr, + Arlington Heights, IL 60004 + + EMail: asingh1@motorola.com + + + Suhail Nanji + Redback Networks, Inc. + 300 Holger Way + Sunnyvale, CA 95134 + + EMail: suhail@redback.com + + + + + + + + + + + + + + + + + + + +Singh, et. al. Standards Track [Page 12] + +RFC 3355 L2TP Over AAL5 August 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Singh, et. al. Standards Track [Page 13] + |