RFC 3355

Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5)

📅 published September 2002, from ietf

RFC 3355: Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5) 🎀

okay bestie, this is RFC 3355 💖 It's from the Network Working Group and it's a Standards Track doc, dated August 2002. The authors are A. Singh (Motorola), R. Turner (Paradyne), R. Tio, and S. Nanji (Redback Networks) 🫶 Nothing is listed as obsoleted or updated, so it's standing on its own ✨

Status of this Memo 📜

so this doc says it specifies an Internet standards track protocol for the Internet community, and it literally asks for discussion and suggestions for improvements 🌈 for the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, periodt 💅

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🦋

the Layer Two Tunneling Protocol (L2TP) gives you a standard way to carry the link layer of the Point-to-Point Protocol (PPP) between a dial-up server and a Network Access Server 🌸 and it does this over a network connection instead of a physical point-to-point connection. This doc is all about using an Asynchronous Transfer Mode (ATM) network for that underlying connection. ATM User-Network Interface (UNI) Signaling Specification Version 4.0 or Version 3.1 with ATM Adaptation Layer 5 (AAL5) are supported as the interfaces to the ATM network ✨

Applicability ✨

this spec is for L2TP implementations that use ATM to provide the communications link between the L2TP Access Concentrator and the L2TP Network Server 🧚

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] lets a dial-up server give access to a remote NSP by extending the PPP connection through a tunnel in a network that both it and the NSP are directly connected to 💫 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] 🙈

there's a list of acronyms at the end of the doc as Appendix A, so you're covered 💖

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 🧃

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.) it's giving "the size limit flows downhill" 📏

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. not me going "that's a whole other project" 🙃

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 🧚

4. Multi-Protocol Encapsulation 🌈

this spec 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. 👑

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. 🧚💅

6. Virtual Circuit Multiplexed L2TP over AAL5 ✨

okay bestie, so VC-multiplexed L2TP over AAL5 is the alternative to LLC encapsulated L2TP over AAL5 💅 The L2TP PDU is just the AAL5 payload with no LLC header at all. People also call this "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 CPCS (Common Part Convergence Sub-layer) PDU payload field holds user information, up to 2^16 - 1 octets. That's a lot of room 🌸

The PAD field pads the CPCS-PDU so it fits exactly into the ATM cells. That way the last 48 octet cell payload made by the SAR sublayer has the CPCS-PDU Trailer right justified in the cell. Very neat, very precise 🎀

The CPCS-UU (User-to-User indication) field carries CPCS user to user information transparently. It does nothing under the multi-protocol ATM encapsulation, so it MAY be set to any value 🙈

The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to 64 bits. Any extra functions are still 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 gives the length of the payload field in octets, with a maximum of 65535 octets. A Length field coded as 0x00 MAY be used for the abort function 💀

The CRC field is computed over the entire CPCS-PDU, except for 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 start at either the LAC or the LNS, no cap 👑 An implementation that supports SVCs MUST be able to both originate and respond to SVC setup requests. Except for the B-LLI IE described below, all the other IEs needed 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. If 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 it doesn't support. Implementations originating a call that offers both protocol encapsulation techniques MUST be able to accept the use of either encapsulation technique. Not me being strict, but this part is non-negotiable 😭

When originating an LLC encapsulated call that is going 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 going 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 the 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. So the User Information layer 3 protocol field is encoded: 0B 80 00 00 5E 00 07. The AAL5 frame's payload field will always contain an L2TP PDU. The SNAP IPI is only employed 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, so it's a whole vibe shift 🥀 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 tried the connection setup MAY consider the called entity unreachable until it's notified that the unreachable entity is available again. The conditions under which an entity decides another is unreachable, and how it decides 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

When an AAL5 SVC connection gets notified as cleared, an Implementation SHALL tear down the tunnel and return the control connection to the idle state. Bye tunnel 👋

9. Security Considerations

Okay, this section is serious, so let's go 🚨 The Layer Two Tunneling Protocol base specification [RFC2661] covers the basic security issues for L2TP tunneling. It's possible that the L2TP over AAL5 tunnel security could be compromised by an attack on the 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 need protection against threats to an ATM switching network are encouraged to use authentication headers, encrypted payloads, and/or the ATM-layer security services described in [AFSEC2]. Protect yourself, periodt 🔐

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 from an earlier document on L2TP over AAL5 by Nagraj Arunkumar, Manu Kaycee, Tim Kwok, and Arthur Lin 🌸

Special thanks to Mike Davison, Arthur Lin, and 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 on 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.
  • [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

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

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

Okay bestie, time for the legal bit, but make it cute 💅 Copyright (C) The Internet Society (2002). All Rights Reserved. 🎀

You're allowed to copy and share this document and translations of it. You can also write derivative works that comment on it, explain it, or help people build it, and publish and distribute those too, in whole or in part, with no restrictions of any kind 🦋 The one catch: the above copyright notice and this paragraph have to be included on every copy and derivative work 🔐

However, this document itself can't be modified in any way 🙈 That means no removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are developing Internet standards, where the copyright procedures in the Internet Standards process must be followed, and translating it into languages other than English 🌈

The permissions here are perpetual, and the Internet Society or its successors or assigns will never revoke them 💜

This document and the information in it are provided on an "AS IS" basis. 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. 🌸💖

📦 where this page comes from