PPP Working Group Vipin Rawat, Rene Tio INTERNET DRAFT Cisco Systems Category: Internet Draft Rohit Verma Title: draft-ietf-pppext-l2tp-fr-00.txt 3Com Corporation Date: June 1998 Layer Two Tunneling Protocol (L2TP) over Frame Relay Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract Layer Two Tunneling Protocol describes a mechanism to tunnel PPP sessions. The protocol has been designed to be independent of the media it runs over. The base specification describes how it should be implemented to Rawat, Verma, Tio expires December 1998 [Page 1] INTERNET DRAFT June 1998 run over UDP and IP. This document describes how the Layer Two Tunneling Protocol MUST be implemented over Frame Relay PVCs and SVCs. Applicability This specification is intended for those implementations which desire to use facilities which are defined for L2TP. These capabilities require a point-to-point relationship between peers, and are not designed for multi-point relationships which is available in Frame Relay and other NBMA environments. 1.0 Introduction L2TP [1] defines a general purpose mechanism for tunneling PPP over various media. By design, it insulates L2TP operation from the details of the media over which it operates. The base protocol specification illustrates how L2TP may be used in IP environments. This draft specifies the encapsulation of L2TP over native Frame Relay and addresses relevant issues. 2.0 Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL, or MANDATORY -- This item is an absolute requirement of the specification. o SHOULD or RECOMMEND -- This item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- This item is truly optional and may be followed or ignored according to the needs of the implementor. 3.0 Problem Space Overview In this section we describe in high level terms the scope of the problem being addressed. Rawat, Verma, Tio expires December 1998 [Page 2] INTERNET DRAFT June 1998 Topology: +-------+ +---------------+ | | PSTN | | Frame Relay | | User--| |----LAC ===| |=== LNS --+ LANs | ISDN | | Cloud | | +-------+ +---------------+ | L2TP Access Concentrator (LAC) is a device attached to the switched network fabric (e.g. PSTN or ISDN) or co-located with a PPP end system capable of handling the L2TP protocol. The LAC need only implement the media over which L2TP is to operate to pass traffic to one or more LNS's. It may tunnel any protocol carried within PPP. L2TP Network Server (LNS) operates on any platform capable of PPP termination. The LNS handles the server side of the L2TP protocol. L2TP is connection-oriented. The LNS and LAC maintain state for each user that is attached to an LAC. A session is created when an end-to-end PPP connection is attempted between a user and the LNS. The datagrams related to a session are sent over the tunnel between the LAC and LNS. A tunnel is defined by an LNS-LAC pair. The tunnel carries PPP datagrams between the LAC and the LNS. L2TP protocol operates at a level above the particular media over which it is carried. However, some details of its connection to media are required to permit interoperable implementations. L2TP over IP/UDP is described in the base draft [1]. Issues related to L2TP over Frame Relay are addressed in later sections of this draft. 4.0 Encapsulation and Packet Format L2TP MUST be able to share a Frame Relay virtual circuit (VC) with other protocols carried over the same VC. The Frame Relay header format for data packet needs to be defined to identify the protocol being carried in the packets. The Frame Relay network MAY NOT understand these formats. All protocols over this circuit MUST encapsulate their packets within a Q.922 frame. Additionally, frames MUST contain information necessary to identify the protocol carried within the frame relay Protocol Data Unit (PDU), thus allowing the receiver to properly process the incoming packet. Rawat, Verma, Tio expires December 1998 [Page 3] INTERNET DRAFT June 1998 The frame format for L2TP is based on SNAP encapsulation as defined in RFC 1490 [5] and FRF3.1 [2]. SNAP format uses NLPID followed by Organizationally Unique Identifier and a PID. NLPID The single octet identifier provides a mechanism to allow easy protocol identification. For L2TP NLPID value 0x80 is used which indicates the presence of SNAP header. OUI & PID The three-octet Organizationally Unique Identifier (OUI) 0x00-00-5E identifies IANA who administers the meaning of the Protocol Identifier (PID) 0x??-?? (PID to be determined pending application to IANA) which follows. Together they identify a distinct protocol. Format of L2TP frames encapsulated in Frame Relay is given in Figure 1. Octet 1 2 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 0x??-?? | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | L2TP packet | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Format for L2TP frames encapsulated in Frame Relay 5.0 MTU Considerations FRF.12 [4] is the Frame Relay Fragmentation Implementation Agreement. If fragmentation is not supported, the two Frame Rawat, Verma, Tio expires December 1998 [Page 4] INTERNET DRAFT June 1998 Relay endpoints MUST support an MTU size of at least PPP Max-Receive-Unit size + PPP header size + maximum L2TP Header Size + Frame Relay header size. Note the PPP header includes both the protocol field plus HDLC framing bytes, which is required by L2TP. The means to co-ordinate the PPP MRU and Frame Relay MTU are left to implementation. 6.0 QOS Issues In general, QoS mechanisms can be roughly provided for with proprietary mechanisms localized within the LAC or LNS. Interworking issues with various QoS implementations is therefore at this time left as a topic for future study. 7.0 Frame Relay and L2TP Interaction In case of Frame Relay SVCs, connection setup will be triggered when L2TP tries to create a tunnel. Details of triggering mechanism are left to 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 case of Frame Relay SVC. These addresses MAY be obtained as tunnel endpoints for a user as defined in [3]. In case of PVCs, the Virtual Circuit to carry L2TP traffic MAY be configured administratively. The endpoints of the tunnel MUST be identified by DLCI, assigned to the PVC at configuration time. This DLCI MAY be obtained as tunnel endpoints for a user as defined in [3]. There SHALL be no framing issues between PPP and Frame Relay. PPP frames received by LAC from remote user are stripped of CRC, link framing, and transparency bytes, encapsulated in L2TP, and forwarded over Frame Relay tunnel. 8.0 Security Considerations Frame Relay, being a circuit-switched media, is typically less pervious to security attacks [6]. If such attacks become prevalent, it may be desirable to implement additional security mechanisms. Currently there is no standard specification for Frame Relay security. The Frame Relay Forum is working on a Frame Relay Privacy Agreement [7] which specifies authentication, encryption, and key exchange facilities. In light of this work, the issue of security will be re-examined at a later date to see if L2TP over Frame Relay specific protection Rawat, Verma, Tio expires December 1998 [Page 5] INTERNET DRAFT June 1998 mechanisms are still required. Meanwhile, if stronger security mechanisms is required, the use of IP as an intermediate transport layer with IPsec for security is RECOMMENDED. 9.0 Acknowledgments Ken Pierce (3Com Corporation), Matt Harper (3Com Corporation) and Rick Dynarski (3Com Corporation) contributed to the editing of this document. 10.0 References [1] Valencia et al., "Layer Two Tunneling Protocol - L2TP", Internet draft (work in progress), draft-ietf- pppext-l2tp-11.txt, May, 1998. [2] Multiprotocol Encapsulation Implementation Agreement, FRF.3.1 , Frame Relay Forum Technical Committee, June 1995 [3] G. Zorn, D. Leifer, A. Rubens, J. Shriver. "RADIUS Attributes for Tunnel Protocol Support." Internet draft (work in progress), draft-ietf-radius-tunnel-auth-05.txt, Microsoft, Ascend Communications, Shiva Corporation, April 1998. [4] Frame Relay Fragmentation Implemenation Agreement, FRF.12, Frame Relay Forum Technical Committee, December 1997 [5] T. Bradley, C. Brown, A. Malis, "Multiprotocol Interconnect over Frame Relay ", RFC 1490, July 1993 [6] B. Patel, B. Aboda. "Securing L2TP using IPSEC." Internet draft (work in progress), draft-ietf-pppext- l2tp-security-02.txt, Intel, Microsoft, May 1998 [7] Frame Relay Privacy Implementation Agreement, DRAFT, Frame Relay Forum Technical Committee, June 1998 11.0 Author's Addresses Rawat, Verma, Tio expires December 1998 [Page 6] INTERNET DRAFT June 1998 Vipin Rawat, Rene Tio Cisco Systems 170 West Tasman Drive San Jose CA 95134-1706 vrawat@cisco.com rtio@cisco.com Rohit Verma 3Com Corporation 1800 W. Central Road Mount Prospect Illinois 60056 Rohit_Verma@mw.3com.com Rawat, Verma, Tio expires December 1998 [Page 7]