RFC 3070

Layer Two Tunneling Protocol (L2TP) over Frame Relay

📅 published February 2001, from ietf

RFC 3070: Layer Two Tunneling Protocol (L2TP) over Frame Relay ✨🎀

RFC 3070 💖 · Network Working Group · February 2001 Category: Standards Track 💜 Authors: V. Rawat (ONI Systems, Inc.), R. Tio, S. Nanji (Redback Networks, Inc.), R. Verma (Deloitte Consulting) Obsoletes / Updates: the document doesn't list anything it obsoletes or updates 🌸

Okay bestie, this one is all about running L2TP (the thing that tunnels PPP sessions) over Frame Relay circuits 🦋 It's giving "network plumbing, but make it slay" 💅

Status of this Memo 🌈

Okay so this document is an Internet standards track protocol spec for the Internet community, and it's asking for discussion and suggestions to make it better 🫶 For the current standardization state and status, you check the "Internet Official Protocol Standards" (STD 1) list. Distribution of this memo is unlimited ✨

Copyright (C) The Internet Society (2001). All Rights Reserved. 🎀

Abstract 🦋

So, L2TP describes a way to tunnel Point-to-Point (PPP) sessions. It's designed so it doesn't care what media it runs over, which is so iconic 👑 The base spec shows how to run it over the User Datagram Protocol (UDP) and the Internet Protocol (IP). This document is the glow-up that explains how L2TP runs over Frame Relay Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs) 💖

Applicability 🌸

This spec is for implementations that want to use the L2TP features it defines. It only applies to the use of Frame Relay pont-to-point circuits 🙈

1.0 Introduction ✨

L2TP [1] is a general purpose mechanism for tunneling PPP over all kinds of media 🧚 By design, it keeps L2TP operation separate from the details of the media underneath. The base protocol spec shows how L2TP may be used in IP environments. This document specifies how L2TP is encapsulated over native Frame Relay and covers the relevant issues 💅

2.0 Conventions 💜

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 RFC 2119 [2] 🫶

3.0 Problem Space Overview 🌈

Here we go over, at a high level, the scope of the problem we're solving 🔥 Here's the topology:

      +------+           +---------------+          |
      | PSTN |           |  Frame Relay  |          |
User--|      |----LAC ===|               |=== LNS --+ LANs
      | ISDN |           |     Cloud     |          |
      +------+           +---------------+          |

An L2TP Access Concentrator (LAC) is a device hooked up to the switched network fabric (like PSTN or ISDN), or it's co-located with a PPP end system that can handle the L2TP protocol 🎀 The LAC only needs to implement the media that L2TP runs over, so it can pass traffic to one or more LNS's. It may tunnel any protocol carried within PPP 🌸

The L2TP Network Server (LNS) runs on any platform that can terminate PPP 💖 It handles the server side of the L2TP protocol. L2TP is connection-oriented, so the LNS and LAC keep state for each user attached to an LAC ✨ A session gets created when an end-to-end PPP connection is attempted between a user and the LNS. The datagrams for a session travel over the tunnel between the LAC and LNS. A tunnel is defined by an LNS-LAC pair, and it carries PPP datagrams between the LAC and the LNS 🦋

L2TP sits at a level above the particular media it's carried over. Still, some details of how it connects to the media are needed for implementations to be interoperable 🧚 L2TP over IP/UDP is covered in the base L2TP spec [1]. The Frame Relay stuff gets handled in later sections of this document 💅

4.0 Encapsulation and Packet Format 🎀

Okay this part is the big one 😭 L2TP MUST be able to share a Frame Relay virtual circuit (VC) with other protocols carried over that same VC 💖 The Frame Relay header format for data packets needs to be defined so it identifies the protocol being carried. The Frame Relay network may not understand these formats 🙈

All protocols over this circuit MUST encapsulate their packets within a Q.922 frame 🫶 Frames also have to include the info needed to identify the protocol carried inside the Frame Relay Protocol Data Unit (PDU), so the receiver can process the incoming packet properly 🔥

The frame format for L2TP MUST be SNAP encapsulation as defined in RFC 1490 [6] and FRF3.1 [3]. SNAP format uses an NLPID followed by an Organizationally Unique Identifier and a PID 👑

NLPID 🌸

The single octet identifier gives a simple way to identify the protocol. For L2TP, the NLPID value 0x80 is used, which indicates that a SNAP header is present ✨

OUI & PID 🦋

The three-octet Organizationally Unique Identifier (OUI) 0x00-00-5E identifies IANA, which administers the meaning of the Protocol Identifier (PID) 0x0007. Together they identify a distinct protocol 💜

Here's the format of L2TP frames encapsulated in Frame Relay, shown in Figure 1 🧚

       Octet                      1
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         1   |         Q.922 Address         |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         3   | Control  0x03 | pad   0       |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         5   | NLPID 0x80    |  OUI  0x00    |
             +-+-+-+-+-+-+-+-+               +
         7   | OUI     0x00-5E               |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         9   | PID     0x0007                |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |                               |
             |          L2TP packet          |
             |                               |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |              FCS              |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 1  Format for L2TP frames encapsulated in
                  Frame Relay

5.0 MTU Considerations 💅

FRF.12 [5] is the Frame Relay Fragmentation Implementation Agreement 🔥 If fragmentation is not supported, the two Frame Relay endpoints MUST support an MTU size of at least 1526. That number comes from adding the PPP Max-Receive-Unit size, the PPP header size, the Max L2TP Header Size, and the Frame Relay header size. (The PPP header size is the protocol field size plus the HDLC framing bytes, which L2TP requires.) 🧚

To avoid packet discards on the Frame Relay interface, the RECOMMENDED default Frame Relay MTU is 1564, based on a PPP default MRU of 1500 🫶 How to make sure these MTU settings are in place is left up to the implementation 🌸

6.0 QOS Issues 🌈

Generally, QoS can be handled with proprietary mechanisms that live locally within the LAC or LNS ✨ QoS considerations are beyond the scope of this document 💜

7.0 Frame Relay and L2TP Interaction 🦋

For Frame Relay SVCs, connection setup gets triggered when L2TP tries to create a tunnel. The details of the triggering mechanism are left to the implementation 🧚 There SHALL NOT be any change in Frame Relay SVC signaling due to L2TP 🙈 The endpoints of the L2TP tunnel MUST be identified by X.121/E.164 addresses in the case of Frame Relay SVC. These addresses MAY be obtained as tunnel endpoints for a user, as defined in [4] 💖

For PVCs, the Virtual Circuit that carries L2TP traffic MAY be configured administratively 👑 The endpoints of the tunnel MUST be identified by DLCI, which is assigned to the PVC at configuration time. This DLCI MAY be obtained as tunnel endpoints for a user, as defined in [4] 🎀

There SHALL be no framing issues between PPP and Frame Relay 🫶 PPP frames the LAC receives from a remote user get stripped of CRC, link framing, and transparency bytes. Then they're encapsulated in L2TP and forwarded over the Frame Relay tunnel 🔥

8.0 Security Considerations 💀

Okay, serious moment 😭 Right now there's no standard specification for Frame Relay security, although the Frame Relay Forum is working on a Frame Relay Privacy Agreement 🙈 Given that work, the security question will be re-examined at a later date, to see whether L2TP over Frame Relay specific protection mechanisms are still required 💅 In the meantime, the basic security issues are discussed in the base L2TP spec [1] 🖤

9.0 Acknowledgments 🌸

Ken Pierce (3Com Corporation) and (Rick Dynarski 3Com Corporation) helped with editing this document 🫶

10.0 References 📚

[1]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
     B. Palter "Layer Two Tunneling Protocol 'L2TP'", RFC 2661,
     August 1999.

[2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

[3]  Multiprotocol Encapsulation Implementation Agreement, FRF.3.1 ,
     Frame Relay Forum Technical Committee, June 1995.

[4]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
     I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
     2868, June 2000.

[5]  Frame Relay Fragmentation Implementation Agreement, FRF.12,
     Frame Relay Forum Technical Committee, December 1997.

[6]  Bradley, T., Brown, C. and A. Malis, "Multiprotocol Interconnect
     over Frame Relay", RFC 1490, July 1993.

11.0 Authors' Addresses 💌

Vipin Rawat
ONI Systems, Inc.
166 Baypointe Parkway
San Jose CA 95134

EMail: vrawat@oni.com


Rene Tio
Redback Networks, Inc.
300 Holger Way
San Jose, CA 95134

EMail: tor@redback.com


Rohit Verma
Deloitte Consulting
180 N. Stetson Avenue
Chicago Illinois 60601

EMail: rverma@dc.com


Suhail Nanji
Redback Networks, Inc.
300 Holger Way
San Jose, CA 95134

EMail: suhail@redback.com

Copyright (C) The Internet Society (2001). 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 🫶

📦 where this page comes from