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