"[1] Typical use of PPPoE involves leveraging the PPP facilities for authenticating the user with a username and password, via the PAP protocol or via CHAP.
On the customer-premises equipment, PPPoE may be implemented either in a unified residential gateway device that handles both DSL modem and IP routing functions or in the case of a simple DSL modem (without routing support), PPPoE may be handled behind it on a separate Ethernet-only router or even directly on a user's computer.
(Support for PPPoE is present in most operating systems, ranging from Windows XP,[3] Linux[4] to Mac OS X.
PPPoE was developed by UUNET, Redback Networks (now Ericsson) and RouterWare (now Wind River Systems) [6] and is available as an informational RFC 2516.
[7] In late 1998, the DSL service model had yet to reach the large scale that would bring prices down to household levels.
[8] Potential equipment vendors and carriers alike recognized that broadband such as cable modem or DSL would eventually replace dialup service, but the hardware (both customer premises and LEC) faced a significant low-quantity cost barrier.
Thus the initial focus was on small and home business customers for whom a ~1.5 Mbit/s T1 line (at the time US$800–1500 per month) was not economical, but who needed more than dialup or ISDN could deliver.
The equipment was available immediately, as was the service, and developing a whole new protocol stack (Microsoft at the time was advocating fiber-based atm-cells-to-the-desktop,[9] and L2TP was brewing as well, but was not near completion) would take so long to implement that the window of opportunity might slip by.
Several decisions were made to simplify implementation and standardization in an effort to deliver a complete solution quickly and at a lower cost.
PPPoE hoped to merge the widespread Ethernet infrastructure with the ubiquitous PPP, allowing vendors to reuse their existing software and deliver products in the very near term.
The second use-case, where the PPPoE protocol trio is used over one or more internet access links reaching upstream to a greater or lesser depth, is, according to consensus, only still used for historical reasons.
Encapsulation is done by prepending the PPP chunks with the 6-byte PPPoE header and carrying them in Ethernet frames with EtherType set to 0x8864.
Here is an example of a PADO packet: AC-Name -> String data holds the AC name, in this case “lpzbr001” (the Arcor DSL-AC in Leipzig) Src.
PPPoE over ATM has the highest overhead of the popular DSL delivery methods, when compared with for example PPPoA (RFC 2364).
[15] However ignoring ATM and IP fragmentation for the moment, the protocol header overheads for ATM payload due to choosing PPP + PPPoEoA can be as high as 44 bytes = 2 bytes (for PPP) + 6 (for PPPoE) + 18 (Ethernet MAC, variable) + 10 (RFC 2684 LLC, variable) + 8 (AAL5 CPCS).
[13][14] Compare this with a vastly more header-efficient protocol, PPP + PPPoA RFC 2364 VC-MUX over ATM+DSL, which has a mere 10-byte overhead within the ATM payload.
However, the true overhead in terms of the total amount of ATM payload data sent is not simply a fixed additional value – it can only be either zero or 48 bytes (leaving aside scenario (iii) mentioned earlier, IP fragmentation).
[11][13] With short packets, the longer the header overheads the greater the likelihood of generating an additional ATM cell.
Unfortunately some DSL services require the use of wasteful LLC headers with PPPoE and do not allow the more efficient VC-MUX option.
This added overhead can mean that a reduced maximum length limit (so-called ‘MTU’ or ‘MRU’) of 1500 − 8 = 1492 bytes is imposed on (for example) IP packets sent or received, as opposed to the usual 1500-byte Ethernet frame payload length limit which applies to standard Ethernet networks.
This capability is advantageous for many users in cases where companies receiving IP packets have (incorrectly) chosen to block all ICMP responses from exiting their network, a bad practice which prevents path MTU discovery from working correctly and which can cause problems for users accessing such networks if they have an MTU of less than 1500 bytes.
In this alternative technology, PPPoE is merely a means of connecting DSL-modems to an Ethernet-only router (again, or to a single host PC).
RFC 4638 allows PPPoE devices to negotiate an MTU of greater than 1492 if the underlying Ethernet layer is capable of jumbo frames.
According to a Cisco document "PPPoEoE is a variant of PPPoE where the Layer 2 transport protocol is now Ethernet or 802.1q VLAN instead of ATM.
RFC 6934, "Applicability of Access Node Control Mechanism to PON based Broadband Networks", which argues for the use of Access Node Control Protocol in PONs for—among other things—authenticating subscriber access and managing their IP addresses, and the first author of which is a Verizon employee, excludes PPPoE as an acceptable encapsulation for GPON: "The protocol encapsulation on BPON is based on multi-protocol encapsulation over ATM Adaptation Layer 5 (AAL5), defined in [RFC2684].
"[23] The 10G-PON (XG-PON) standard (G.987) provides for 802.1X mutual authentication of the ONU and OLT, besides the OMCI method carried forward from G.984.
[24] G.987 also adds support for authenticating other customer-premises equipment beyond the ONU (e.g. in a MDU), although this is limited to Ethernet ports, also handled via 802.1X.
[26] The Broadband Forum's TR-200 "Using EPON in the Context of TR-101" (2011), which also pertains to 10G-EPON, says "The OLT and the multiple-subscriber ONU MUST be able to perform the PPPoE Intermediate Agent function, as specified in Section 3.9.2/TR-101.
[28] (This book assumes that PPPoE is leveraged for other features of PPP besides encapsulation, including IPCP for host configuration, and PAP or CHAP for authentication.)
There are security reasons to use PPPoE in a (non-DSL/ATM) shared-medium environment, such as power line communication networks, in order to create separate tunnels for each customer.