Network Working Group W. M. Townsley
Internet-Draft cisco Systems
Ron da Silva
<draft-dasilva-l2tp-relaysvc-00.txt> 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 <draft-
dasilva-l2tp-relaysvc-00.txt> 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]
