Network Working Group W. M. Townsley Internet-Draft cisco Systems Ron da Silva AOL Time Warner November 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''. 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 May 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 November 2001 Contents Status of this Memo.......................................... 1 1.0 Introduction.......................................... 2 2.0 L2TP Service Relay for PPPoE Protocol Operation....... 3 2.1 PPPoE PAD Message Exchange Coherency.................. 3 2.2 PPPoE Service Relay Capabilities Negotiation.......... 3 2.2.1 PPPoE Service Relay Response Capability AVP...... 4 2.2.2 PPPoE Service Relay Request Capability AVP....... 4 2.3 PPPoE Active Discovery Operation...................... 5 2.4 Session Establishment and Teardown.................... 6 3.0 L2TP Service Relay Messages........................... 6 3.1 Service Relay Request Message (SRRQ).................. 6 3.2 Service Relay Reply Message (SRRP).................... 7 4.0 PPPoE Relay AVP....................................... 7 5.0 Security Considerations............................... 7 6.0 IANA Considerations................................... 8 7.0 Acknowledgements...................................... 8 8.0 References............................................ 8 9.0 Author's Addresses.................................... 8 1.0 Introduction 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 a remote L2TP node. 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. 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 Townsley, da Silva. [Page 2] INTERNET DRAFT L2TP Active Discovery Relay for PPPoE November 2001 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.0 L2TP Service Relay for PPPoE Protocol Operation When PPPoE PAD messages are received at a PPPoE Access Concentrator, the messages are passed over the L2TP control connection via a newly defined (see Section 3.1) Service Relay Request Message (SRRQ) on an established tunnel. When received, the PPPoE PAD message is processed at the L2TP node, or relayed to another L2TP node or PPPoE Access Concentrator. PPPoE PAD messages sent as replies are handled in a similar manner over a newly defined (see Section 3.2) Service Relay Reply Message (SRRP) allowing the PPPoE client to exchange messages to remote L2TP nodes which can process PPPoE PAD messages for service advertisement and selection. 2.1 PPPoE PAD Message Exchange Coherency PPPoE PAD messages may arrive from multiple ethernet interfaces and be relayed across multiple L2TP control connections. Measures must be taken to ensure that the relayed PAD messages are not delivered to the wrong destination. There are two mechanisms defined in PPPoE available to ensure this, the PPPoE AC Cookie TAG [PPPoE], and the PPPoE Relay Session ID TAG [PPPoE]. An LAC MUST include a PPPoE Relay-Session-Id TAG in a relayed PPPoE PAD message. Any response MUST echo this TAG as well. An LAC MUST use this TAG to determine which control connection this response was received over, and which PPPoE client any relayed message should be sent to. For L2TP to L2TP tunnel switching, the PPPoE-Relay- Session-Id TAG may change at each hop, as long as the proper TAG is restored and echoed back to each node. An LAC MUST include a PPPoE AC-Cookie in any message sent to a PPPoE client. Any response MUST echo this TAG as well. An LAC MUST use this TAG to determine which PPPoE client the response was received from, and which control connection a relayed message should be sent to. PPPoE PAD messages are always sent in their entirety, including ethernet framing beginning at the MAC addressess, within the PPPoE PAD Relay AVP. It is not necessary to include any padding bytes which may be present at the end of the ethernet frame. 2.2 PPPoE Service Relay Capabilities Negotiation If the extensions defined in this document are present and configured for operation on a given control channel, one or more of the Townsley, da Silva. [Page 3] INTERNET DRAFT L2TP Active Discovery Relay for PPPoE November 2001 following AVPs MUST be present in the SCCRQ or SCCRP messages during control connection setup. 2.2.1 PPPoE Service Relay Response Capability AVP The PPPoE Service Relay Response Capability AVP, Attribute Type TBA, indicates to an L2TP peer that if an SRRQ message is received, it will be processed or relayed to another node, and that an SRRP message may be expected in response. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H| rsvd | Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Vendor ID is the IETF Vendor ID of 0. This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP may be set to 0 or 1. If the sender of this AVP does not wish to establish a connection to a peer which does not understand this L2TP extension, it SHOULD set the M bit to 1, otherwise it MUST be set to 0. The Length of this AVP is 6. The AVP may be present in the following messages: SCCRQ, SCCRP 2.2.2 PPPoE Service Relay Request Capability AVP The PPPoE Service Relay Request Capability AVP, Attribute Type TBA, indicates to an L2TP peer that the SRRQ message may be sent buy this L2TP endpoint. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H| rsvd | Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Vendor ID is the IETF Vendor ID of 0. This AVP MAY be hidden (the H bit MAY be 0 or 1). Townsley, da Silva. [Page 4] INTERNET DRAFT L2TP Active Discovery Relay for PPPoE November 2001 The M bit for this AVP may be set to 0 or 1. If the sender of this AVP does not wish to establish a connection to a peer which does not understand this L2TP extension, it SHOULD set the M bit to 1, otherwise it MUST be set to 0. The Length of this AVP is 6. The AVP may be present in the following messages: SCCRQ, SCCRP 2.3 PPPoE Active Discovery Operation When a PPPoE PADI is received by an L2TP LAC that is providing PPPoE Service Relay, the PADI MUST be packaged in its entirety within the L2TP PPPoE PAD Relay AVP and transmitted over established L2TP control connection(s) associated with the interface on which the PADI arrived. The PPPoE PAD Relay AVP is sent via the Service Relay Request (SRRQ) message. The PPPoE Relay-Session-ID MUST be included in the relayed PPPoE message as described in Section 2.1. The SRRQ message may only be sent to an L2TP node which included the PPPoE Service Relay Response Capability AVP during control connection establishment. If no acceptable control connection is available or cannot be initiatiated, operation MUST fall back to a local policy to handle the response (or intentional lack of response) to the PADI. It is a matter of policy as to which control connections will be established for relay and associated with an interface. For instance, an implementation may "nail up" a control connection to a particular L2TP destination and associate the connection with an interface which PPPoE PADI packets will arrive. Upon receipt of the SRRQ, the included PPPoE PADI message MUST be processed as described in [PPPoE], or be relayed to another L2TP control connection. The operation of relaying the PADI to another node over L2TP is identical to relaying the message as if it were received natively at a PPPoE Access Concentrator. After processing of a PADI, any resultant PADO MUST be encapsulated in a PPPoE PAD Relay AVP and delivered via the Service Relay Reply (SRRP) message to the sender of the SRRQ. The PADO MUST include the PPPoE AC Cookie AVP. Upon receipt of an SRRP message with relayed PADO, an LAC MUST send the encapsulated PADO message to the corresponding PPPoE Host. 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. The PADO MUST include the PPPoE AC Cookie TAG. Townsley, da Silva. [Page 5] INTERNET DRAFT L2TP Active Discovery Relay for PPPoE November 2001 2.4 Session Establishment and Teardown When an LAC that is providing the PPPoE Service Relay feature receives a valid PADR (and matching the AC Cookie TAG sent in the PADO), the LAC MUST treat this an an action for creation of a Incoming Call Request as defined in the L2TP specification [L2TP]. The resultant ICRQ message MUST contain the PPPoE PAD Relay AVP containing the PADR in its entirety, and a PPPoE Relay-Session-Id TAG. 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. 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. 3.0 L2TP Service Relay Messages 3.1 Service Relay Request Message (SRRQ) The Service Relay Request Message (SRRQ), Message Type TBD, is sent by an LAC to relay requests for services. This document defines one AVP that may be present to request service, the PPPoE PADI sent as an AVP as described in section 2.0. Further service relay mechanisms may Townsley, da Silva. [Page 6] INTERNET DRAFT L2TP Active Discovery Relay for PPPoE November 2001 also use this message in a similiar context. Discussion of other service relay mechanisms are outside the scope of this document. 3.2 Service Relay Reply Message (SRRP) The Service Relay Request Message (SRRP), Message Type TBD, is sent by an L2TP node in response to request for service advertisement. This document defines one AVP that may be present to respond to a service request, the PPPoE PADO sent as an AVP in as described in section 2.0. Further service relay mechanisms may also use this message in a similiar context. Discussion of other service relay mechanisms are outside the scope of this document. 4.0 PPPoE Relay AVP The PPPoE Relay PAD AVP, Attribute Type TBA, carries the entire PADI, PADO, PADR, PADS and PADT messages within it. This is the only AVP necessary for Relay of all PADx messages via L2TP. New PAD messages MAY be tunneled via this AVP as well. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H| rsvd | Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | PPPoE PAD Message ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... (Until end of message is reached) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Vendor ID is the IETF Vendor ID of 0. This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP may be set to 0 or 1. If the sender of this AVP does not wish to establish a connection to a peer which does not understand this L2TP extension, it SHOULD set the M bit to 1, otherwise it MUST be set to 0. The Length of this AVP is 6 plus the length of the PPPoE PAD Message. The AVP may be present in the following messages: SRRQ, SRRP, ICRQ, ICRP, ICCN, and CDN. 5.0 Security Considerations TBD Townsley, da Silva. [Page 7] INTERNET DRAFT L2TP Active Discovery Relay for PPPoE November 2001 6.0 IANA Considerations Two new L2TP Message Types are required, SRRQ (Section 3.1) and SRRP (Section 3.2). Three new AVP attributes are required (Section 4.0, 2.3). 7.0 Acknowledgements Thanks to Vinay Shankarkumar for review and comment. 8.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 9.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 8]