RFC 3817
Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE)
Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE) ✨
- RFC number: 3817 💖
- Category: Informational 🎀
- Date: June 2004 🦋
- Authors: W. Townsley (cisco Systems) and R. da Silva (AOL Time Warner) 👑
- Obsoletes / Updates: Its title block has no Obsoletes or Updates line, so this RFC doesn't obsolete or update anything 💅
Status of This Memo 🌸
okay so this memo is just for information, bestie. It is not an Internet standard of any kind. You can distribute it as much as you want, since distribution is unlimited 🫶
Copyright Notice 📜
Copyright (C) The Internet Society (2004).
Abstract 🧚
PPP is the standard way to send multi-protocol datagrams over point-to-point links 🔥 L2TP lets you tunnel PPP packets across a packet-switched network in the middle 🦋 and then PPPoE shows you how to build PPP sessions and wrap PPP packets inside Ethernet 💅 It's giving three protocols working together 😭
This RFC describes a way to relay Active Discovery and Service Selection from PPPoE over the reliable control channel in L2TP 💖 It defines two new L2TP control message types, plus PPPoE-specific Attribute Value Pairs (AVPs) for L2TP 🎀 The result is much tighter integration of one particular PPPoE feature with L2TP, and it's honestly iconic ✨
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 2
2.1. PPPoE Active Discovery Stage . . . . . . . . . . . . . . 3
2.2. Session Establishment and Teardown . . . . . . . . . . . 4
2.3. PPPoE PAD Message Exchange Coherency . . . . . . . . . . 6
2.4. PPPoE Service Relay Capabilities Negotiation . . . . . . 8
2.4.1. PPPoE Service Relay Response Capability AVP. . . 8
2.4.2. PPPoE Service Relay Forward Capability AVP . . . 9
3. L2TP Service Relay Messages. . . . . . . . . . . . . . . . . . 9
3.1. Service Relay Request Message (SRRQ) . . . . . . . . . . 9
3.2. Service Relay Reply Message (SRRP) . . . . . . . . . . . 10
4. PPPoE Relay AVP. . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A: PPPoE Relay in Point to Multipoint Environments. . . . 13
Appendix B: PAD Message Exchange Coherency Examples. . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 171. Introduction 💫
okay so PPPoE [1] is super often paired with L2TP [2] to carry PPP [3] frames over a network that's way past the local Ethernet a PPPoE Host is plugged into 🌈 For example, PPP frames tunneled inside PPPoE can get picked up by an L2TP Access Concentrator (LAC) and then tunneled to any L2TP Network Server (LNS) you can reach over an IP network 😭
Also, PPPoE has its own simple way to discover the services offered by PPPoE Access Concentrators (PPPoE AC) that are reachable over Ethernet from the PPPoE Host 💅 The packets in that exchange aren't carried over PPP, so they don't get tunneled with the PPP packets over L2TP. That means the discovery negotiation can't go past the LAC without adding some new functionality 🙈
This document shows a simple way to relay PPPoE Active Discovery (PAD) messages over L2TP. You pull the PAD messages out and send them over the L2TP control channel 🦋 Once setup is done and the PAD messages have been processed, PPP packets arriving over PPPoE get tunneled over L2TP the usual way, as defined in L2TP [2] 🎀 So there are no data plane changes needed at the LAC or LNS to support this, which is honestly so clean 🧚 Plus, by using the L2TP control channel, the PPPoE discovery mechanism gets carried to the LNS reliably, before any L2TP sessions exist, and it can take advantage of any special treatment applied to control messages in transit or on receipt ✨
2. Protocol Operation 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4] 💜
When PPPoE PAD messages arrive at a PPPoE Access Concentrator, they get passed over the L2TP control connection in a brand-new Service Relay Request Message (SRRQ) on an established tunnel (Section 3.1) 🫶 Once it's received, the PPPoE PAD message is either processed at the L2TP node or relayed to another L2TP node or PPPoE Access Concentrator 🔥 PPPoE PAD messages that are sent as replies are handled the same way, but over a newly defined Service Relay Reply Message (SRRP) (Section 3.2) 💖
2.1. PPPoE Active Discovery Stage 🌸
When a PPPoE Active Discovery Initiation packet (PADI) shows up at an L2TP LAC that's providing PPPoE Service Relay, the PADI MUST be packaged in its entirety (including the Ethernet MAC header) inside the PPPoE Relay AVP. Then it gets transmitted over the established L2TP Control Connection(s) associated with the interface the PADI arrived on 👑
The PPPoE Relay AVP is sent via the Service Relay Request Message (SRRQ) defined in Section 3. The SRRQ message MUST NOT be sent to an L2TP node that did not include the PPPoE Service Relay Response Capability AVP during control connection establishment 🙈 If no acceptable control connection is available or can't be created, PPPoE PAD operation MUST be handled locally by some means (including intentionally ignoring the PPPoE PAD message, though this must be a deliberate act) 💀
Which control connections get established for relay, and associated with a given interface, is a matter of local policy. The same goes for when those Control Connections get established 🧚 For instance, an implementation may "nail up" a control connection to a particular L2TP destination and associate that connection with an interface where PPPoE PADI packets will arrive. Or, an implementation might dynamically establish a Control Connection to a predetermined destination when a PADI is received, or when a PADI is received from a particular source ✨
When the SRRQ is received, the included PPPoE PADI message MUST be processed as described in [3], relayed to another L2TP control connection, or relayed to another PPPoE AC 💅
After a PADI is processed, any resulting PPPoE Active Discovery Offer packet (PADO) MUST be encapsulated in a PPPoE Relay AVP and delivered via the Service Relay Reply Message (SRRP) to the sender of the SRRQ 🦋
When an SRRP message carrying a relayed PADO is received, a LAC MUST send the encapsulated PADO message to the corresponding PPPoE Host 🎀 The source MAC address of the PADO message MUST be one that the LAC will respond to, which may mean substituting its own MAC address 🌈
In each exchange above, the PPPoE Host-Uniq TAG or AC-Cookie TAG MUST be used as described in Section 2.3 💖
Here's an example of the PAD exchange between a PPPoE Host, LAC, and LNS up to this point, assuming the L2TP Control Connection has already been established. Examples that include AC-Cookie TAG and Host-Uniq TAG operation are in the Appendix 🫶
PPPoE Host LAC Tunnel Switch LNS
PADI ->
SRRQ (w/PADI) -> SRRQ (w/PADI) ->
<- SRRP (w/PADO) <- SRRP (w/PADO)
<- PADO2.2. Session Establishment and Teardown 🎀
okay so when a LAC that's doing the PPPoE Service Relay thing gets a valid PPPoE Active Discovery Request packet (PADR) 💅, the LAC MUST treat this as an action for creation of a Incoming Call Request (ICRQ) as defined in [2]. The resultant ICRQ message MUST contain the PPPoE Relay AVP containing the PADR in its entirety. the whole PADR rides along inside that AVP, no cap 🦋
Once the LNS gets that L2TP ICRQ, it parses the PADR as described in [3]. If it's an acceptable PPPoE service connection (e.g., the Service-Name-Error TAG would not be included in a PPPoE Active Discovery Session-confirmation packet (PADS) response) ✨, the L2TP Incoming-Call-Reply (ICRP) message that gets sent back to the LAC includes the resultant PPPoE PADS wrapped up in the PPPoE Relay AVP. but if the service is unacceptable 💀, the PADS with a Service-Name-Error Tag gets delivered via the Relay Session AVP inside a Call-Disconnect-Notify (CDN) message, and that also tears down the L2TP session. also the PPPoE PADS SESSION_ID in the PPPoE Relay AVP MUST always be zero, because the LAC is the one who picks it and fills it in 🫶
When the LAC gets an ICRP with the PPPoE Relay AVP, it parses the PADS out of the AVP, inserts a valid PPPoE SESSION_ID, and responds to the PPPoE Host with the PADS. the MAC address of the PADS MUST be the same one that was used during the PADI/PADO exchange described above 👑. the LAC also finishes the L2TP session establishment by sending an Incoming-Call-Connected (ICCN) to the LNS, and it binds the L2TP session with the PPPoE session. at this point PPP data packets can flow between the PPPoE session and the L2TP session in the traditional manner 🌈
Teardown is a whole mood too 😭. If the L2TP session gets torn down for any reason, the LAC MUST send a PPPoE Active Discovery Terminate packet (PADT) to the host to indicate that the connection has been terminated. This PADT MAY be received from the LNS via the PPPoE Relay AVP within a CDN message if this was a graceful shutdown initiated by the PPPoE subsystem at the LNS. same as with the PADS, the SESSION_ID in the PADT message is zero until the LAC fills in the proper SESSION_ID 🧚
If the LAC receives a PADT from the PPPoE Host, the L2TP session MUST be shut down via the standard procedures defined in [2]. The PADT MUST be sent in the CDN message to the LNS via the PPPoE Relay AVP. if the PPPoE system at the LNS disconnects the session, a PADT SHOULD be sent in the CDN. and if the LAC gets a disconnect from L2TP and didn't receive a PADT, it MUST generate a properly formatted PADT and send it to the PPPoE Host as described in [3] 🥹
Session Establishment
PPPoE Host LAC Tunnel Switch LNS
PADR ->
ICRQ (w/PADR) ->
ICRQ (w/PADR) ->
<- ICRP (w/PADS)
<- ICRP (w/PADS)
<- PADS
ICCN ->
ICCN ->Session Teardown (LNS Initiated)
PPPoE Host LAC Tunnel Switch LNS
<- CDN (w/PADT)
<- CDN (w/PADT)
<- PADTSession Teardown (Host Initiated)
PPPoE Host LAC Tunnel Switch LNS
PADT ->
CDN (w/PADT) ->
CDN (w/PADT) ->2.3. PPPoE PAD Message Exchange Coherency 🔥
PPPoE PAD messages are gonna arrive from multiple ethernet interfaces and get relayed across multiple L2TP control connections. so to track which PAD messages have to be sent where, we use the Host-Uniq TAG and AC-Cookie TAG 💖. each one gets used in the same manner, depending on which PAD message is being sent or replied to. they both take advantage of the fact that any PAD message sent as a reply to another PAD message MUST echo these TAGs in their entirety [3] 🎀
For this discussion, it helps to define two "directions" that PAD messages travel during a relayed PPPoE PAD message exchange. so for the following example:
"Upstream" ----------------------->
PPPoE Host ------ LAC ----- Tunnel Switch ------ LNS
<--------------------- "Downstream"PAD messages being sent from the PPPoE Host, through the LAC, Tunnel Switch, and LNS, are defined to be traversing "Upstream." PAD messages being sent in the opposite direction are defined to be traversing "Downstream." 🧭
here's the observation to keep in mind for this example:
- PAD messages that are sent Upstream: PADI, PADR, PADT
- PAD messages that are sent Downstream: PADO, PADS, PADT
there's a request/response connection between the PADI and PADO that has to be linked with some common value. similarly, there's a request/response connection between PADO and PADR. the PADS is sent on its own with no response, but it must be delivered to the sender of the PADR. and the PADT must be sent with the same SESSION_ID as established in the PADS 🦋
the goal for PAD message exchange coherency is to make sure the connections between PADI/PADO, PADO/PADR, PADR/PADS, and PADS/PADT all stay intact as the PAD messages get relayed from node to node. that's the whole vibe 💅
the basic mechanism for keeping PADI, PADO, and PADR messages tied together is the AC-Cookie TAG and Host-Uniq TAG. both of these TAGs are defined as arbitrary data that must be echoed in any message sent as a response to another message. this is the key to tying these PAD messages together at each hop. the following two rules make this possible:
For PAD messages that are sent Upstream, a new Host-Uniq TAG MUST be inserted at each relaying node before the PAD message is forwarded. There SHOULD be at most one Host-Uniq TAG per PAD message. For PAD messages being sent Downstream, a new AC-Cookie TAG MUST be inserted at each relaying node before the PAD message is forwarded. There SHOULD be at most one AC-Cookie TAG per PAD message. Additionally, for an LNS receiving multiple PAD messages from upstream, there SHOULD be at most one PAD message forwarded downstream per received SRRP Message. In other words, there SHOULD be exactly one PPPoE Relay AVP per L2TP SRRP Message.
the exceptions are the PADS, which cannot carry an AC-Cookie TAG (and, thankfully, doesn't need to), and the PADT. we'll get to those later in this section 🙈. using the rules above, PADI, PADO, and PADR messages can be relayed through an arbitrary number of nodes, with each node inserting its own value to link a message response that it might receive 🌸
so to do this exchange without tying up resources at each L2TP node, it's desirable to not require ephemeral state at each node waiting for a message response from each forwarded PAD message. this is achievable if you're willing to be very intelligent about the values sent in the PPPoE TAGs used for message coherency 🧠. given that the TAGs are of arbitrary size and composition and are always echoed in their entirety, you can use that info to map any next relay hop information. for example, the L2TP Tunnel ID (Control Connection ID) could be encoded in the TAG so you know where to relay the message when it arrives. if you choose this method, the encoding MUST incorporate some method of encryption and authentication of the value. this is actually a pretty simple proposition, since only the source of the encrypted data will ever need to decrypt and authenticate the value upon receipt (so no key exchanges are necessary, and any of a myriad of algorithms may be chosen) 🔐. note that individual TAGs MUST never exceed 255 octets in length, and the length of an entire PPPoE message MUST never exceed the maximum segment size of the underlying ethernet. if a TAG does go over 255 octets, a compression scheme (which may include storing state at an L2TP node) may be necessary before constructing a new TAG 😬
The PADS and PADT messages don't rely on the AC-Cookie TAG or Host-Uniq TAG for getting directed to the proper node. as described in Section 2.2, the L2TP session is created upon receipt of a valid PADR at the L2TP LAC. since the PADS is sent as an AVP on this message exchange, its coherency may be secured via the L2TP session itself ✨. same goes for the PADT, since it's carried in the L2TP disconnect message (CDN) for the L2TP session 🫶
clients are supposed to treat an AC-Cookie TAG as an opaque object. they tell PADOs apart only by MAC address, Service-Name TAG(s), and AC-Name TAG(s). if an LAC sends multiple PADOs, they should contain different AC-Name TAGs 🍓
also, a node doing PPPoE L2TP Relay (like an LAC) SHOULD attempt to distinguish or rate limit retransmitted PADx messages (perhaps via the source MAC address and/or arriving interface of the message) so it doesn't overload L2TP 🌈
examples of this operation for a bunch of scenarios, plus considerations for certain deployment situations, can be found in the Appendix of this document 📚
2.4. PPPoE Service Relay Capabilities Negotiation 💜
if the extensions defined in this document are present and configured for operation on a given Control Connection, the AVPs listed in this section MUST be present in the Start-Control-Connection-Request (SCCRQ) or Start-Control-Connection-Reply (SCCRP) messages during control connection setup 👑
2.4.1. PPPoE Service Relay Response Capability AVP 🦋
The PPPoE Service Relay Response Capability AVP, Attribute Type 56, tells an L2TP peer that the PPPoE Service Relay (SRRQ, SRRP) messages and the PPPoE Relay AVP will be processed and responded to when received 💖
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.4.2. PPPoE Service Relay Forward Capability AVP 💅
Okay bestie, the PPPoE Service Relay Forward Capability AVP is Attribute Type 57 🎀. It tells an L2TP peer that it's cool for PPPoE Service Relay messages (SRRQ and SRRP) and the PPPoE Relay AVP to come from this peer 🦋. Here's the layout:
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. Not gonna lie, this M bit stuff is kind of a big deal 👑.
The Length of this AVP is 6. ✨
The AVP may be present in the following messages: SCCRQ, SCCRP 💖
3. L2TP Service Relay Messages 🧚
This section identifies two new L2TP messages used to deliver PPPoE PADI and PADO messages. Two new messages, both main character energy 💅🔥
3.1. Service Relay Request Message (SRRQ) 🦋
The Service Relay Request Message (SRRQ), Message Type 18, is sent by an LAC to relay requests for services. This document defines one new AVP that may be present to request service in section 2. Further service relay mechanisms may also use this message in a similar context. Discussion of other service relay mechanisms are outside the scope of this document. The other mechanisms are their own story, bestie 💜
3.2. Service Relay Reply Message (SRRP) 🌈
The Service Relay Reply Message (SRRP), Message Type 19, is sent by an LAC to relay responses of requests for services. This document defines one new AVP that may be present as a response to a request for service in section 2. Further service relay mechanisms may also use this message in a similar context. Discussion of other service relay mechanisms are outside the scope of this document. Same deal as SRRQ, the rest is out of scope 🫶
4. PPPoE Relay AVP ✨
The PPPoE Relay AVP, Attribute Type 55, carries the entire PADI, PADO, PADR, PADS and PADT messages within, including Ethernet MAC source and destination addresses. This is the only AVP necessary for relay of all PAD messages via L2TP. Literally the only one you need, iconic 😭
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. Same M bit energy as before, periodt 💅
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. Whole list of messages, no cap 🧚
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. Bestie, this is the scary part 😭
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. Not me clutching my pearls 🙈
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]. So if the info is sensitive and it's crossing an untrusted network, you MUST use one of these two. Non-negotiable 🔥🫶
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].
- PPPoE Relay AVP (section 4.0)
- PPPoE Relay Response Capability AVP (section 2.4.1)
- 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].
- Service Relay Request Message (SRRQ) (Section 3.1)
- 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. IANA gets a pretty chill job here 🌈
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. The real MVPs 🦋
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. Lots of possibilities, bestie 🧚
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. Overreplicating is not it, so be careful 😭
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. Right now nobody's doing it, but that could change 💖
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. One at a time, bestie, no group chat blasts 🫶🎀
Appendix B: PAD Message Exchange Coherency Examples 🎀
okay so bestie, this appendix is where the PAD messages actually get walked through step by step, and it's giving very "watch the packets dance" energy 💃✨ every example is copied exactly below so nobody gets confused about which Host-Uniq or AC-Cookie is which 🫶
Example 1: "PPPoE Relay With Multiple LNSs" 🌸
,--- LNS1
/
Host --- LAC
\
`--- LNS2this one assumes there's a good reason to send a copy of the PADI to both LNSs (e.g., each LNS may have a different service profile to offer) 👀 so the LAC is basically the friend passing notes to two different groups 💌
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 ---- LNS2this is the chain version, where every hop passes the baton along 🏃♀️💨
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
\
`--- AC2in this one, AC1 and AC2 are PPPoE access concentrators sitting on a broadcast domain 📡 here's how the whole sequence goes down 💅
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.netRon da Silva
AOL Time Warner
12100 Sunrise Valley Dr
Reston, VA 20191
EMail: rdasilva@va.rr.comFull Copyright Statement ⭐
the copyright belongs to The Internet Society (2004) 📜 this document is covered by the rights, licenses and restrictions in BCP 78, and apart from what's set out there, the authors keep all their rights 🔒
the document and everything in it are provided "AS IS". 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 doesn't take a position on whether any Intellectual Property Rights or other rights claimed to apply to the technology in this document are valid or how far they reach, or whether any license for them would be available 🤷♀️ it also doesn't say it has made any independent effort to find such rights. info about how rights work for RFC documents is in BCP 78 and BCP 79 📚
copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission for implementers or users of this spec can be found through the IETF's online IPR repository at http://www.ietf.org/ipr 🔗
the IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💖
Acknowledgement 🫶
funding for the RFC Editor function is currently provided by the Internet Society 💜
📦 where this page comes from
- ietf: rfc3817 2004-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms