Network Working Group W. M. Townsley Internet-Draft cisco Systems Ron da Silva AOL Time Warner July 2001 L2TP Active Discovery Relay for PPPoE Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as and expires January 31, 2002. Please send comments to the L2TP mailing list (l2tp@l2tp.net). Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract L2TP Active Discovery Relay for PPPoE describes a method for relay of PPPoE Active Discovery and Service Selection [PPPoE] over the reliable L2TP control channel [L2TP]. Two new L2TP control message types and associated PPPoE-specific AVPs are defined. This relay mechanism provides enhanced integration in L2TP of a specific feature in the PPPoE tunneling protocol. Townsley, da Silva. [Page 1] INTERNET DRAFT L2TP Active Discovery Relay for PPPoE July 2001 Contents Status of this Memo.......................................... 1 1.0 L2TP Service Relay.................................... 2 2.0 L2TP Service Relay for PPPoE Overview................. 2 2.1 L2TP Service Relay for PPPoE Details.................. 3 2.1.1 Service Discovery................................ 3 2.2.2 Session Establishment and Teardown............... 3 3.0 L2TP Service Relay Messages........................... 5 3.1 L2TP Service Relay Request Message (SRRQ)............. 5 3.2 L2TP Service Relay Reply Message (SRRP)............... 5 4.0 L2TP PPPoE Relay AVP.................................. 5 5.0 Security Considerations............................... 5 6.0 IANA Considerations................................... 5 7.0 References............................................ 5 8.0 Author's Addresses.................................... 6 1.0 L2TP Service Relay L2TP relay services may be obtained via an exchange of the L2TP Service Relay Request (SRRQ) and L2TP Service Relay Reply (SRRP) messages (defined in section 3.0) over an already established L2TP control connection. These new message types may include AVP(s) that are used to relay specific advertisement and selection information. The SRRQ contains AVP(s) that carry service request information. The SRRP contains AVP(s) that provide service availability information in response to the SRRQ AVP(s). 2.0 L2TP Service Relay for PPPoE Overview PPPoE is often deployed in conjunction with L2TP to carry PPP frames over a network beyond the reach of the local Ethernet network to which the PPPoE Host is connected. For example, PPP frames tunneled within PPPoE may be transported over L2TP to any LNS reachable over an IP network. [PPPoE] defines a method for discovering services offered by PPPoE Access Concentrators that are reachable via broadcast Ethernet from the PPPoE Host. It may be desirable to extend the PPPoE discovery exchange over L2TP to allow service availability information to be advertised by the LNS. Integrating the active discovery exchange of PPPoE with the L2TP control channel is a simple and reliable method to provide this capability. This may be done without the burden of tunneling all Ethernet frames, and by extension PPPoE, in its entirety. Townsley, da Silva. [Page 2] INTERNET DRAFT L2TP Active Discovery Relay for PPPoE July 2001 Integration of Active Discovery between PPPoE and L2TP is achieved by carrying PPPoE PADI, PADO, PADR, PADS and PADT information in the L2TP Service Relay control messages. By utilizing the reliable delivery of L2TP control messages, the PPPoE discovery mechanism is transported to the LNS in a reliable manner and may take advantage of any special treatment to give to control messages in transit. Tunneled PPP frames from the PPPoE packets are then transported over L2TP in the traditional manner as defined in [L2TP]. Thus, no special data processing is required by the LNS to transport the tunneled PPP frames. 2.1 L2TP Service Relay for PPPoE Details 2.1.1 Service Discovery When a PPPoE PADI is received by an L2TP LAC that is providing the PPPoE Service Relay, the PADI MUST be packaged in its entirety within the L2TP PPPoE PAD Relay AVP and transmitted to the LNS or set of LNS's via the L2TP Service Relay Request (SRRQ) Message. The LAC SHOULD insert the PPPoE Relay-Session-Id TAG [PPPoE] into the PPPoE PADI message. If the PPPoE PADI is being forwarded to multiple LNSs, the LAC MUST insert a unique PPPoE Relay-Session-Id TAG for each LNS to which the PPPoE PADI is being forwarded. Upon receipt of the L2TP Service Relay Request (SRRQ) message with an L2TP PPPoE PAD Relay AVP present, the LNS MUST process the PPPoE PADI message as described in [PPPoE] if configured to do so. If the PADI message results in a PADO message to be sent, it MUST then be packaged in the L2TP PPPoE PAD Relay AVP (preserving the PPPoE Relay-Session-Id TAG as described in [PPPoE] if present) and sent to the LAC via the L2TP Service Relay Reply Message (SRRP). As with any PPPoE AC, it is valid to not generate a PADO message, and thus not reply to an L2TP Service Relay Request (SRRQ) message when processing the relayed PADI message. Upon receipt of an L2TP Service Relay Reply (SRRP) message with the L2TP PPPoE PAD Relay AVP present, an LAC MUST send the encapsulated PADO message to the PPPoE Host (along with the PPPoE Relay-Session-Id TAG when present). The source MAC address of the PADO message MUST be one which the LAC will respond to, perhaps requiring substitution of its own MAC address. If relaying to multiple LNSs, the LAC MAY choose a different MAC address for each LNS. Further, if multiple LNSs respond with PADO messages, the host SHOULD differentiate all PADO messages sent by the LAC by insertion of a unique PPPoE Relay-Session-Id TAG as described in [PPPoE]. 2.2.2 Session Establishment and Teardown When an LAC that is providing the PPPoE Service Relay feature receives a PADR, it MUST attempt to establish an L2TP connection with an LNS via Townsley, da Silva. [Page 3] INTERNET DRAFT L2TP Active Discovery Relay for PPPoE July 2001 the procedure defined in [L2TP] for an Incoming Call. Should a PPPoE Relay-Session-Id TAG be present that was previously assigned by this LAC, the PPPoE Relay-Session-Id TAG SHOULD be used to determine to which LNS among a set of LNS's that the L2TP connection is to be made. Alternatively (though not preferred), the MAC address MAY be used if a different one was used in the PADO for each LNS. As an example, an implementation might assign the Relay-Session-Id TAG in the PADO to be equal to a locally known identifier for the LNS to which the PPPoE PADI was originally sent. The L2TP connection entails generation of an ICRQ message to be sent over the control connection to the LNS. This ICRQ message MUST contain the PPPoE PAD Relay AVP within the ICRQ message containing the PADR in its entirety. Upon receipt of an L2TP ICRQ message, the LNS parses the PADR message as described in [PPPoE]. If this is an acceptable PPPoE service connection (e.g. the Service-Name-Error TAG would not be included), an L2TP ICRP message is sent to the LAC with the PPPoE PADS encapsulated with the PPPoE PAD Message Relay AVP. If the service is unacceptable, the PADS is delivered via the same AVP within a CDN message if the shutdown was initiated gracefully by the PPPoE subsystem at the LNS. The PPPoE PADS SESSION_ID in the L2TP PPPoE PAD Relay AVP MUST always be zero (it will be filled in by the LAC). Upon receipt of an ICRP with the L2TP PPPoE PAD Relay AVP, the LAC parses the PADS from the AVP, inserts a valid PPPoE SESSION_ID, and responds to the PPPoE Host with the PADS. The MAC address of the PADO MUST be the same as that which was utilized during the PADI/PADO exchange described above. The LAC also sends an ICCN to the LNS and binds the L2TP session with the PPPoE session. PPP data packets may now flow from the PPPoE session to the L2TP session. In all PPPoE PAD messages, the PPPoE Relay-Session-Id TAG MUST be preserved when assigned as described in [PPPoE]. If the L2TP session is torn down for any reason, the LAC MUST send a PADT to the host to indicate that the connection has been terminated. This PADT MAY be received from the LNS via the L2TP PPPoE PAD Relay AVP within a CDN message if this was a graceful shutdown initiated by the PPPoE subsystem at the LNS. The SESSION_ID in the relayed PADT message is zero and filled in with the proper SESSION_ID at the LAC. If the LAC receives a PADT from the PPPoE Host, the L2TP session MUST be shut down the standard procedures defined in [L2TP]. The PADT MUST be sent in the CDN message to the LNS via the L2TP PPPoE PAD Relay AVP. Townsley, da Silva. [Page 4] INTERNET DRAFT L2TP Active Discovery Relay for PPPoE July 2001 3.0 L2TP Service Relay Messages 3.1 L2TP Service Relay Request Message (SRRQ) The L2TP Service Relay Request Message (SRRQ) is sent to relay requests for services. This message may contain zero or more L2TP Service Relay AVPs as defined in section 4.0. For example, a PPPoE PADI may be sent as an AVP in this message as described in section 2.0. 3.2 L2TP Service Relay Reply Message (SRRP) The L2TP Service Relay Reply Message (SRRP) is sent in response to an L2TP Service Relay Request Message (SRRQ). It contains relayed service information advertised by the LNS. This message may contain zero or more L2TP Service Relay AVPs as defined in section 4.0. For example, a PPPoE PADO may be sent as an AVP in this message as described in section 2.0. 4.0 L2TP PPPoE Relay AVP Only one new AVP is necessary for Relay of all PADx messages via L2TP. The PPPoE Relay PAD AVP carries the entire PADI, PADO, PADR, PADS and PADT messages within it. New PAD messages MAY be tunneled via this AVP as well. 5.0 Security Considerations TBD 6.0 IANA Considerations Two new L2TP Message Types are required, SRRQ (section 3.1) and SRRP (section 3.2). One new AVP value is required (section 4.0). 7.0 References [PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994 [L2TP] Townsley, Valencia, Rubens, Pall, Zorn, Palter, "Layer Two Tunnel- ing Protocol 'L2TP'", RFC 2661, June 1999 [PPPoE] Mamakos, Lidl, Evarts, Carrel, Simone, Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999 Townsley, da Silva. [Page 5] INTERNET DRAFT L2TP Active Discovery Relay for PPPoE July 2001 8.0 Author's Addresses W. Mark Townsley cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 mark@townsley.net Ron da Silva AOL Time Warner 12100 Sunrise Valley Dr Reston, VA 20191 ron@aol.net Townsley, da Silva. [Page 6]