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. Security Considerations
PPPoE has a number of known security weaknesses that are not
described here. For example, an intruder between a PPPoE Host and a
PPPoE AC who can observe or modify PPPoE Active Discovery traffic has
numerous opportunities for denial of service and other attacks. The
use of the L2TP extensions described here makes it possible to tunnel
PPPoE discovery packets between the LAC and LNS, extending the path
which the PPPoE Active Discovery packets are transported. There are
two possible implications of this. First, the tunneled packets may
now be observable by an intruder having access to traffic along the
L2TP tunnel path. This MAY make information regarding service
offerings or host identity easier to obtain to a rogue party given
that it is being sent over a wider variety of media, and presumably
over a longer distance and/or more hops or administrative domains.
Whether this information could be used for malicious purposes depends
on the information contained within, but it is conceivable that this
could be sensitive information, and this mechanism increases the
possibility that this information would be presented to an
interloper. Second, it may also be possible for an intruder to
modify PPPoE Active Discovery traffic while it is being carried
within L2TP control messages.
There are at least two methods defined to help thwart this inspection
or modification by an unauthorized individual. One of the two MUST
be used if the service discovery information is considered to be
sensitive and is traversing an untrusted network. The first
suggested method is AVP hiding described in [2]. This may be used to
hide the contents of the packets in transit, though offers no
integrity protection against modification of data in the AVP. The
second and more secure method is protecting L2TP with IPsec as
defined in [6].
6. IANA Considerations
This document requires three new "AVP Attribute" (attribute type)
numbers to be assigned through IETF Consensus [5] as indicated in
Section 10.1 of [2].
1. PPPoE Relay AVP (section 4.0)
2. PPPoE Relay Response Capability AVP (section 2.4.1)
3. PPPoE Relay Forward Capability AVP (section 2.4.2)
This document requires two new "Message Type" numbers to be assigned
through IETF Consensus [5] as indicated in Section 10.2 of [2].
1. Service Relay Request Message (SRRQ) (Section 3.1)
2. Service Relay Reply Message (SRRP) (Section 3.2)
There are no additional requirements on IANA to manage numbers in
this document or assign any other numbers.
7. Acknowledgements
Thanks to Vinay Shankarkumar for valuable review, comment, and
implementation.
Thanks to David Skoll and a number of others on pppoe@ipsec.org for
providing very helpful discussion about their PPPoE implementations.
Thanks to Ross Wheeler, Louis Mamakos, and David Carrel for providing
valuable clarifications of PPPoE [1] while designing this protocol.
8. References
8.1. Normative References
[1] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and R.
Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)",
RFC 2516, February 1999.
[2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B.
Palter, "Layer Two Tunneling Protocol ’L2TP’", RFC 2661, August
1999.
[3] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
8.2. Informative References
[6] Patel, B., Aboba, B., Dixon, W., Zorn, G. and S. Booth, "Securing
L2TP Using IPsec," RFC 3193, November 2001.
Appendix A: PPPoE Relay in Point to Multipoint Environments
The PPPoE PADI message in its native form, is sent as a broadcast
message on an Ethernet link. Thus, more than one AC concentrator
could conceivably receive and respond to this message. Similarly, a
PPPoE interface could be associated with more than one L2TP Control
Connection, in order to query multiple LNSs with potentially varying
service profiles, as well as to load balance requests.
As the PADI message is propagated, one may choose to replicate the
message to multiple Control Connections in order to mimic the
behavior of the PADI being sent on an ethernet link with multiple ACs
attached. If the number of replicated nodes is large, and the number
of hops deep, then an unmanageable "fan-out" of PADI propagation may
occur. Thus, care should be taken here to only replicate messages to
multiple Control Connections when it is absolutely necessary.
The only case where it is seems necessary to replicate messages to
multiple destinations is in the case where each destination is known
to have varying service policies that all need to be advertised to a
PPPoE Host for its gathering and selection. At the time of this
writing, the authors know of no PPPoE Host implementations that take
advantage of this ability (instead, responding to only a single PPPoE
PADO). This, of course, is subject to change if and when PPPoE
implementations are advanced to this stage.
In cases where multiple Control Connections may exist to multiple
LNSs for load balancing purposes, L2TP Service Relay should take
measures to try one Control Connection at a time, rather than
broadcasting to all Control Connections simultaneously.
Appendix B: PAD Message Exchange Coherency Examples
Example 1: "PPPoE Relay With Multiple LNSs"
,--- LNS1
/
Host --- LAC
\
`--- LNS2
This example assumes that there is good reason to send a copy of the
PADI to both LNSs (e.g., each LNS may have a different service
profile to offer).
1) a. Host sends PADI via broadcast MAC address to LAC
b. LAC replicates the PADI message and forwards a copy to LNS1
Host-Uniq = R1 (assigned)
c. LAC replicates the PADI message and forwards a copy to LNS2
Host-Uniq = R2 (assigned)
2) a. LNS1 responds with PADO to LAC
Host-Uniq = R1 (echoed)
AC-Cookie = C1 (assigned)
b. LNS1 responds with PADO to LAC
Host-Uniq = R2 (echoed)
AC-Cookie = C2 (assigned)
c. LAC forwards both PADO messages to Host with source MAC set to
MAC address of LAC. PADO from (2a) is assigned new AC-Cookie
C1’ and PADO from (2b) is given AC-Cookie C2’
3) a. Host sends PADR to MAC address of LAC (choosing one)
AC-Cookie = C1’ (echoed)
b. LAC knows to forward PADR to LNS1 based on C1’
AC-Cookie = C1 (echoed)
4) Session Establishment at the LAC commences, with further PAD
messages carried within the context of the L2TP session itself.
No need to inspect the AC-Cookie TAG or Host-Uniq TAG from this
point forward in order to direct messages properly.
Example 2: "PPPoE Relay With L2TP Tunnel-Switching"
Host --- LAC ---- LNS1 ---- LNS2
1) a. Host sends PADI to LAC.
b. LAC sends PADI to LNS1
Host-Uniq = R1 (assigned)
c. LNS1 sends PADI to LNS2
Host-Uniq = R2 (assigned)
2) a. LNS2 responds to LNS1 with PADO
Host-Uniq = R2 (echoed)
AC-Cookie = C1 (assigned)
b. LNS1 relays PADO to LAC
Host-Uniq = R1 (echoed)
AC-Cookie = C1’ (assigned)
c. LAC sends PADO to Host
AC-Cookie = C1’’ (assigned)
3) a. Host sends PADR to MAC address of LAC
AC-Cookie = C1’’ (echoed)
b. LAC sends PADR to LNS1
AC-Cookie = C1’ (echoed)
c. LNS1 sends PADR to LNS2
AC-Cookie = C1 (echoed)
4) Session Establishment at the LAC, LNS1 and LNS2 commences, with
further PAD messages carried within the context of the L2TP
session itself. No need to inspect the AC-Cookie TAG or Host-Uniq
TAG from this point forward in order to direct messages properly.
Example 3: "PPPoE Relay With Multiple PPPoE ACs"
,--- AC1
/
Host --- LAC ---- LNS
\
`--- AC2
In this example, AC1 and AC2 are PPPoE access concentrators on a
broadcast domain. Sequence of operation is as follows.
1) a. Host sends PADI to LAC.
b. LAC sends PADI to LNS
Host-Uniq = R1 (assigned)
c. LNS broadcasts PADI to AC1 and AC2
Host-Uniq = R2 (assigned)
2) a. AC1 sends PADO to LNS
Host-Uniq = R2 (echoed)
AC-Cookie = C1 (assigned)
b. AC2 sends PADO to LNS
Host-Uniq = R2 (echoed)
AC-Cookie = C2 (assigned)
c. LNS sends two PADOs to LAC
Host-Uniq = R1 (echoed)
AC-Cookie (assigned) = C1’ and C2’, respectively
d. LAC sends two PADOs to Host
Host-Uniq = R1
AC-Cookie (assigned) = C1’’ and C2’’, respectively
3) a. Host sends PADR with to LAC to select service from AC2.
AC-Cookie = C2’’ (echoed)
b. LAC sends PADR to LNS AC-Cookie = C2’ (echoed)
c. LAC sends PADR to AC2
AC-Cookie = C1 (echoed)
4) Session Establishment at the LAC, LNS and AC2 commences, with
further PAD messages carried within the context of the L2TP
session or PPPoE session itself. No need to inspect
the AC-Cookie TAG or Host-Uniq TAG from this point forward in
order to direct messages properly.
Authors’ Addresses
W. Mark Townsley
cisco Systems
7025 Kit Creek Road
Research Triangle Park, NC 27709
EMail: mark@townsley.net
Ron da Silva
AOL Time Warner
12100 Sunrise Valley Dr
Reston, VA 20191
EMail: rdasilva@va.rr.com
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.