INTERNET DRAFT M. Higashiyama Expires May 2002 Anritsu November 2001 Ethernet Over L2TP (EoL2TP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Layer 2 Tunneling Protocol (L2TP) [RFC2661] provides a standard method for tunneling PPP sessions between a L2TP Access Concentrator (LAC) and a L2TP Network Server (LNS). This document defines the mechanism to tunnel Ethernet and IEEE 802.3 media access control (MAC) frames (including [IEEE 802.1Q] VLAN datagrams) with L2TP. Expires May 2002 [Page 1] Internet Draft Ethernet Over L2TP November 2001 Table of Contents 1. Introduction .......................................... 2 2. Conventions ........................................... 3 3. Motivation ............................................ 3 4. EoL2TP framework ...................................... 3 4.1 What is EoL2TP? ................................. 3 4.2 Why use L2TP tunnels? ........................... 4 4.3 Why use PPP? .................................... 4 5. Models for network configuration ...................... 4 5.1 LAN to LAN connection ........................... 4 5.2 HOST to LAN model ............................... 8 5.3 Consideration for xDSL networks ................. 9 6. Requirements for EoL2TP ............................... 10 6.1 Scaling ......................................... 10 6.2 Redundancy and avoiding broadcast loops ......... 10 6.3 Flexibility ..................................... 10 6.4 Reliability ..................................... 11 7. BCP/L2TP versus Direct encapsulation .................. 11 7.1 Header Overhead in frames ....................... 11 7.2 Reliability ..................................... 12 8. Security Considerations ............................... 13 9. Intellectual Property Notice .......................... 13 References ................................................... 13 Authors' Addresses ........................................... 14 1. Introduction L2TP [RFC2661] defines the procedures for tunneling PPP [RFC1661] sessions between a so-called L2TP Access Concentrator (LAC) and a L2TP Network Server (LNS). BCP [RFC2878] defines the procedures for carrying Ethernet Frames on PPP connections. The combination of the two standards allows users to make a remote connection from a host to a LAN or from a LAN to a LAN transparently. This technology is used to tunnel Ethernet and IEEE 802.3 media access control (MAC) frames (including [IEEE 802.1Q] VLAN datagrams) with L2TP. In this document, we define this technology as Ethernet over L2TP or EoL2TP. The issues, requirements, architecture and network model of EoL2TP are different from those of L2TP. This document intends to provide a framework for EoL2TP and documents its issues, requirements, architecture and network model. Expires May 2002 [Page 2] Internet Draft Ethernet Over L2TP November 2001 2. 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 [RFC2119]. 3. Motivation In an intranet, many kind of protocols are used such as DECNET, XNS, AppleTalk, and Banyan. Some of these may be non-routed protocols, or they may be protocols that users do not want to route for some reason. In this situation, they want to bridge these protocols. If the users's sites are in two different locations, the technology for tunneling Ethernet frames is applied to connect two or more remote sites. Tunneling Ethernet frames MAY provide one kind of Virtual Private Network. But this motivation, usage, requirement, architecture and network model are different from traditional VPNs. Users often want to use Virtual LANs as defined in [IEEE 802.1Q] because VLANs are widely used today and useful to multiplex traffic from different LANs on one connection. For this purpose, many tunneling technologies are described in IETF documents, including "BCP: Bridge Control Protocol over PPP" [RFC2878] and "Ethernet over ATM" [RFC1483]. Several others have been proposed in IETF working groups. Tunneling Ethernet frames over L2TP is usefull because L2TP is well- designed to Tunneling multi-protocols over Internet or ATM network. 4. EoL2TP framework 4.1 What is EoL2TP? EoL2TP is a technology that transports Ethernet Frame on L2TP tunnels. The goal of EoL2TP is to make a connecteion between a remote site or system and an LNS located at a local LAN via L2TP tunnels. EoL2TP bridges packets between two different LANs transparently and safely. Expires May 2002 [Page 3] Internet Draft Ethernet Over L2TP November 2001 The EoL2TP architecture model is illustrated in Fig 1. +----------------------+ | MAC entity | +----------------------+ | BCP | +----------------------+ | PPP | +----------------------+ | L2TP | +----------------------+ Fig 1: EoL2TP architecture 4.2 Why use L2TP tunnels? L2TP is the standard protocol that provides a mechanism for aggregation of multiple Layer 2 connections across packet oriented data networks. It is widely used to build Remote VPNs. EoL2TP works on L2TP to provide mechanisms for security, aggregation, and a multi-service framework. 4.3 Why use PPP? There are many benefits from using PPP. PPP has LQM (Link Quality Management) that allows the user to check the health of the path. PPP has authentication, encryption and compression. These PPP benefits bring flexibility and reliability to users. 5. Models for network configuration This section describes some types of models of EoL2TP that we will consider. The first model is a LAN to LAN connection. A LAN to LAN connection provides connectivity for many-to-many communication. The second model is a HOST to LAN connection. A HOST to LAN connection provides connectivity for one-to-many communication. 5.1 LAN to LAN connection A LAN to LAN connection assumes the scenario of connecting a remote LAN to a central LAN. It MAY use a dial connection or a leased line connection. Expires May 2002 [Page 4] Internet Draft Ethernet Over L2TP November 2001 ------------- --------- +-----+ ( ) +-----+ --------- ( Remote )---| NAS |---( IP Backbone )---| GW |---( Central ) ( LAN ) +-----+ ( ) +-----+ ( LAN ) --------- ------------- --------- In this model, we can consider two different types of scenarios. One is compulsory tunneling and the other is voluntary tunneling. 5.1.1 LAN to LAN: Compulsory tunnel model Compulsory tunneling refers to the model in which a network node or gateway connects to a network access server acting as a LAC via a dial connection or leased-line. The LAC entity in the access server extends a PPP session across a backbone using L2TP to a remote LNS. This operation is transparent to the user initiating the PPP session to the LAC. In the Compulsory tunneling model, there are a number of different deployment scenarios possible. In one example, the remote bridge with PPP is located at the customer edge. The customer edge device may be a gateway that can act as a router and/or bridge. The PPP and BCP entity is required on the gateway at the remote LAN in this case. --------- --------- +----+ +-----+ ( ) +----+ --------- ( Remote )-| GW |----| NAS |---( IP )---| GW |----( Central ) ( LAN ) +----+ +-----+ ( Backborn) +----+ ( LAN ) --------- --------- --------- <---- L2TP Tunnel -----> <-------------- PPP Session -------> Fig 3: Compulsory Tunneling Example Expires May 2002 [Page 5] Internet Draft Ethernet Over L2TP November 2001 In the example shown in Fig 3, the gateway at the remote LAN is a MAC bridge defined by [IEEE 802.1D]. The protocol stack of the gateway is shown below: Gateway or RAS +------------------+ | MAC | +---------+--------+ Gateway | BCP | | +-------------+ +---------+ LAN | | MAC | NAS | PPP | Phy | +------+------+ +--------------+ +---------+ | | LAN | BCP | | L2TP LAC | | L2TP LNS| | | Phy +------+ +------+-------+ +---------+ | | | PPP | | | IP/UDP| | IP/UDP | | | +------+ | +-------+ +---------+ | | | Media| | Media| Media | | Media | | +------+------+ +------+-------+ +---------+--------+ | | | | | | ======= +---------+ +---- . . . --+ ======== Remote Access IP Backbone Central LAN network LAN Fig 4: Compulsory Tunneling protocol stack 5.1.2 LAN to LAN: Voluntary tunnel model The L2TP specification has support for voluntary tunneling. In the voluntary tunneling model, the LAC entity can be located on a host, as well as on a network node. Note that such a host MAY have two IP addresses: one for the LAC-LNS IP tunnel, and the other for the network to which the host is connecting. If the user isn't running IP over that tunneled PPP session, then he has no IP address there. +----+ |Host|----- ------------- +----+ / +-----+ ( ) +-----+ --------- /----| NAS |---( IP Backbone )---| GW |----( Corp. ) dial +-----+ ( ) +-----+ ( Network ) connection ------------- --------- <-------------- L2TP Tunnel --------------> with LAC on host <-------------- PPP Session --------------> LNS on gateway Fig 5: Voluntary Tunneling Expires May 2002 [Page 6] Internet Draft Ethernet Over L2TP November 2001 If we consider the EoL2TP application with voluntary tunneling, the LAC and PPP entities are implemented on the remote bridge. --------- --------- +----+ +-----+ ( ) +----+ --------- ( Remote )-| GW |----| NAS |---( IP )---| GW |----( Central ) ( LAN ) +----+ +-----+ ( Backbone) +----+ ( LAN ) --------- --------- --------- <-------------- L2TP Tunnel -------> with <-------------- PPP Session -------> Fig 6: Voluntary Tunneling Example In the example shown in Fig 6, the gateway at the remote LAN is a MAC bridge defined by [IEEE 802.1D] and acts as a LAC. The protocol stack of the gateway is shown below: Gateway or RAS +---------------+ +------------------+ | MAC | | MAC | +------+--------+ +---------+--------+ | | BCP | | BCP | | | +--------+ +---------+ LAN | | | PPP | | PPP | Phy | | +--------+ +---------+ | | LAN |L2TP LAC| | L2TP LNS| | | Phy +--------+ +--------------+ +---------+ | | | IP/UDP | | IP | | IP/UDP | | | +--------+ +------+-------| +---------+ | | | Media | | Media| Media | | Media | | +------+--------+ +------+-------+ +---------+--------+ | | | | | | ======== +-----------+ +---- . . . --+ ======== Remote Access IP Backbone Central LAN network LAN Fig 7: Compulsory Tunneling protocol stack Expires May 2002 [Page 7] Internet Draft Ethernet Over L2TP November 2001 5.2 HOST to LAN model A HOST to LAN connection assumes the scenario of connecting a remote host to a central LAN. It MAY use a dial connection or leased line connection. ------------- +------+ +-----+ ( ) +-----+ --------- | HOST |-----| NAS |---( IP Backbone )---| GW |----( Central ) +------+ +-----+ ( ) +-----+ ( LAN ) ------------- --------- <---------------- L2TP Tunnel -------> with <---------------- PPP Session -------> Fig 8: HOST to LAN Example In this example, the PPP and BCP entity is located on the remote host. The protocol stack of the model is shown below: Remote host +-----------------+ | IP/IPX/AppleTalk| | SNA/Banyan/etc | Gateway or RAS +-----------------+ +------------------+ | MAC | | MAC | +-----------------+ +---------+--------+ | BCP | | BCP | | +-----------------+ +---------+ LAN | | PPP | | PPP | Phy | +-----------------+ +---------+ | | L2TP LAC | | L2TP LNS| | +-----------------+ +--------------+ +---------+ | | IP/UDP | | IP | | IP/UDP | | +-----------------+ +------+-------| +---------+ | | Media | | Media| Media | | Media | | +------=----------+ +------+-------+ +---------+--------+ | | | | | +-----------+ +---- . . . --+ ======== Access IP Backbone Central network LAN Fig 9: HOST to LAN protocol stack Expires May 2002 [Page 8] Internet Draft Ethernet Over L2TP November 2001 5.3 Consideration for xDSL networks xDSL access networks are popular today. PPP is used in xDSL access. The configuration and protocol stack are different from dial-up lines and leased lines as we discussed in section 5.1 and 5.2. An xDSL modem or xDSL router is used at the edge of the customer network. Usually, hosts in the customer network connect with the xDSL modem or xDSL router via Ethernet using PPPoE (Note: PPPoE is not standards- track protocol). The xDSL line from the customer site is terminated by DSL access multiplexers (DSLAM) at the provider edge. The DSLAM forwards traffic to the ISP router. We assume several situations for how the ISP router deals with traffic: - ISP router terminates the PPP session. - ISP router acts as L2TP LAC and tunnels traffic to the central network. The protocol stack architecture and a L2TP usage example are below: Host ISP router +-----+ +----------------+ | IP | xDSL modem | L2TP LAC | +-----+ +------+----------+ +----------------+ | PPP | | | AAL5 | DSLAM | PPPoE | IP/UDP | +-----+ |Ethernet---------+ +--------------+ +-------+--------+ |PPPoE| | | ATM | | ATM | | Ether | | +-----+ | +----------+ +------+-------| +-------+ Media | |Ether| | | xDSL | | xDSL | ATM | ATM/AAL5| | +-----+ +------+----------+ +------+-------+ +-------+--------+ | | | | | | | ============= +-----------+ +--------+ +----- Ethernet xDSL ATM IP backbone diagram less useful. For PPPoE, it looks something like this: We have many options to implement EoL2TP in the xDSL model. One example shown in below expecting PPPoE will implement on xDSL router and it function as a Bridge. Expires May 2002 [Page 9] Internet Draft Ethernet Over L2TP November 2001 xDSL router +-----------------+ | MAC | +------+----------+ | | BCP | ISP router | +----------+ +----------------+ | | PPP | | L2TP LAC | | LAN +----------+ +----------------+ | Phy | PPPoE | DSLAM | PPPoE | IP/UDP | | +----------+ +--------------+ +-------+--------+ | | ATM | | ATM | | Ether | | | +----------+ +------+-------| +-------+ Media | | | xDSL | | xDSL | ATM | ATM/AAL5| | +------+----------+ +------+-------+ +-------+--------+ | | | | | | ===== +-----------+ +--------+ +------- xDSL ATM IP backbone 6. Requirements for EoL2TP 6.1 Scaling The device interconnecting LAN and tunneled network using BCP in EoL2TP framework MUST act as a MAC Bridge defined in [IEEE 802.1D]. To achieve connection of several tens or hundred of LANs, scalability SHOULD be considered. Especially for Layer 2 connections, the implementation SHOULD support efficiency for traffic. The learning and filtering is required for implementation to avoid flooding unnecessary forwarding traffic across the Internet. 6.2 Redundancy and avoiding broadcast loops The device interconnecting LAN and tunneled network using BCP in EoL2TP framework SHOULD act as a MAC Bridge defined in [IEEE 802.1D]. The Spanning Tree Protocol allows the administrator to configure the network with redundant links while avoiding accidental forwarding loops. 6.3 Compatibility The device interconnecting a LAN and a tunneled network using BCP in EoL2TP framework MUST support 802.1Q. And EoL2TP SHOULD be independent from future changes to the IEEE 802.1 standards. For this reason, existing protocols that already track the IEEE standards are preferred. Expires May 2002 [Page 10] Internet Draft Ethernet Over L2TP November 2001 The compatibility to the IEEE 802.1 standards allow many administrators understand it and know how to use it. 6.4 Reliability EoL2TP implementation is RECOMMENDED to support PPP LQM. The LQM allows EoL2TP to fail over in the case where there are redundant paths with Spanning Tree Protocol or Link Aggregation. 7. BCP/L2TP versus Direct encapsulation There was an alternate idea that allowed binding an Ethernet frame on a L2TP message field directly without a PPP header. It is in a work- in-progress. We call this "Direct encapsulation". 7.1 Header Overhead in frames A frame format of EoL2TP (with ACFC and PFC enabled and F bit set to 0) looks like this: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ns (opt) | Nr (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset Size (opt) | Offset pad... (opt) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x31 |0|0|Z|0| Pads | MAC Type | Dest MAC Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dest MAC Addr | Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source MAC Address | Length/Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length/Type | LLC data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAN FCS (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires May 2002 [Page 11] Internet Draft Ethernet Over L2TP November 2001 A frame format of "Direct encapsulation" looks like this: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ns (opt) | Nr (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset Size (opt) | Offset pad... (opt) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC-32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EoL2TP has an added overhead of three octets compared to "Direct Encapsulation". In the case of a 64 byte minimum packet size, EoL2TP adds at most 3.8 percent overhead, which is very small. In addition, if it is not necessary to carry the LAN FCS end to end, the LAN FCS field in the BCP of EoL2TP is optional. This option can remove the four octets of LAN FCS, so the result is one octet shorter than "Direct Encapsulation". In addition, BCP allows Tinygram compression. This means that EoL2TP packets with Tinygram compression are more efficient than "Direct encapsulation" packets. The many PPP and BCP options that are available bring many benefits to EoL2TP. 7.2 Reliability EoL2TP uses a PPP framework, so the PPP LQM is available in EoL2TP. The LQM allows EoL2TP to fail over in the case where there are redundant paths with Spanning Tree Protocol or Link Aggregation. Expires May 2002 [Page 12] Internet Draft Ethernet Over L2TP November 2001 8. Security Considerations EoL2TP does not define any specific security mechanism but instead relies PPP and L2TP. This means security mechanisms in PPP such as PAP/CHAP/ECP are applicable on EoL2TP. Tunnel authentication of L2TP is also applicable. Data encryption can be established by IPsec in the case of L2TP over UDP/IP. 9. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat." The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. References [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter, "Layer 2 Tunneling Protocol "L2TP" ", RFC2661, August 1999. [IEEE 802.1D] IEEE 802.1D-1998, "Information technology - Telecommunications and Information exchange between systems - Local and metropolitan area networks - Common Specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998. Expires May 2002 [Page 13] Internet Draft Ethernet Over L2TP November 2001 [IEEE 802.1Q] IEEE 802.1Q, ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", 1998. [RFC2878] Mitsuru H. and Baker, "PPP Bridging Control Protocol (BCP)", RFC 2878, July 2000. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, Telecom Finland, July 1993. Authors' Addresses Mitsuru Higashiyama Anritsu Corporation 1800 Onna, Atsugi-shi, Kanagawa-prf., 243-8555 Japan Phone: +81 (46) 296-6625 EMail: Mitsuru.Higashiyama@yy.anritsu.co.jp Expires May 2002 [Page 14]