View source for Point-to-Point Protocol over Ethernet

{{Short description|Computer networking protocol}}
{{redirect-distinguish|PPPoE|PoE}}
{| border="0" cellspacing="3" style="float:right;padding-left:15px"
|+ '''PPPoE and TCP/IP [[protocol stack]]'''
|-
|  style="text-align:center; background:#feb;"| ''Application''
|  style="text-align:center; background:#eef;"| [[File Transfer Protocol|FTP]]
|  style="text-align:center; background:#eef;"| [[SMTP]]
|  style="text-align:center; background:#eef;"| [[HTTP]]
|  style="text-align:center; background:#eef;"| ...
|  style="text-align:center; background:#eef;"| [[Domain Name System|DNS]]
|  style="text-align:center; background:#eef;"| ...
|-
|  style="text-align:center; background:#feb;"| ''Transport''
| colspan="4"  style="text-align:center; background:#eef;"| [[Transmission Control Protocol|TCP]]
| colspan="2"  style="text-align:center; background:#eef;"| [[User Datagram Protocol|UDP]]
|-
|  style="text-align:center; background:#feb;"| ''Internet''
| colspan="3"  style="text-align:center; background:#eef;"| [[Internet Protocol|IP]]
| colspan="3"  style="text-align:center; background:#eef;"| [[IPv6]]
|-
| rowspan="3"  style="text-align:center; background:#fc9;"| '''Network access'''
| colspan="6"  style="text-align:center; background:#eef;"| [[Point-to-Point Protocol|PPP]]
|-
| colspan="6"  style="text-align:center; background:#99f;"| '''PPPoE'''
|-
| colspan="6"  style="text-align:center; background:#eee;"| [[Ethernet]]
|}

The '''Point-to-Point Protocol over Ethernet''' ('''PPPoE''') is a [[network protocol]] for [[Encapsulation (networking)|encapsulating]] [[Point-to-Point Protocol]] (PPP) frames inside [[Ethernet]] frames. It appeared in 1999, in the context of the boom of [[DSL]] as the solution for [[tunneling protocol|tunneling]] [[network packet|packet]]s over the DSL connection to the [[ISP]]'s [[Internet Protocol|IP]] network, and from there to the rest of the [[Internet]]. A 2005 networking book noted that "Most DSL providers use PPPoE, which provides [[authentication]], [[encryption]], and [[Data compression|compression]]."<ref name="Boney2005">{{cite book|author=James Boney|title=Cisco IOS in a Nutshell|url=https://books.google.com/books?id=zxq78zNHH7YC&pg=PA88|year=2005|publisher=O'Reilly Media, Inc.|isbn=978-0-596-55311-1|page=88}}</ref> Typical use of  PPPoE involves leveraging the PPP facilities for authenticating the user with a username and password, via the [[Password Authentication Protocol|PAP]] protocol or via [[Challenge-Handshake Authentication Protocol|CHAP]]. PAP was dominant in 2007 but service providers have been transitioning to the more secure CHAP, because PAP is a plain-text protocol.<ref name="GoldenDedieu2007"/> Around 2000, PPPoE was also starting to become a replacement method for talking to a modem connected to a computer or [[Router (computing)|router]] over an Ethernet [[LAN]] displacing the older method, which had been [[USB]]. This use-case, connecting routers to modems over Ethernet is still extremely common today.

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]],<ref>{{Cite web |url=http://support.microsoft.com/kb/283070 |title=How to create a PPPoE connection in Windows XP |access-date=11 December 2013 |archive-date=3 December 2013 |archive-url=https://web.archive.org/web/20131203070724/http://support.microsoft.com/kb/283070 |url-status=dead }}</ref> [[Linux]]<ref>{{cite web|url=http://www.tldp.org/HOWTO/DSL-HOWTO/configure.html|title=Configuring Linux|website=www.tldp.org|access-date=26 March 2019}}</ref> to [[Mac OS X]].<ref>{{cite web|url=https://support.apple.com/en-us/HT201696|title=Connecting to the Internet with PPPoE (Mac OS X v10.5 and earlier)|website=Apple Support|access-date=26 March 2019}}</ref>) More recently{{when|date=June 2020|reason=PPPoE with GPON is mentioned in ITU-T recommendation G,984.1 (03/2008) "Gigabit-capable passive optical networks (GPON): General characteristics" in section I.3.2 "Data functions."}}, some [[GPON]]-based (instead of DSL-based) residential gateways also use PPPoE, although the status of PPPoE in the GPON standards is marginal though mentioned in ITU-T recommendation G.984.1 "'''Gigabit-capable passive optical networks (GPON): General characteristics"'''.

PPPoE was developed by [[UUNET]], [[Redback Networks]] (now Ericsson) and RouterWare (now [[Wind River Systems]]) <ref>[http://findarticles.com/p/articles/mi_m0WUB/is_1999_July_5/ai_55071818/ Wind River Systems Acquires RouterWare, Inc.]. Findarticles.com (1999-07-05). Retrieved on 2011-09-27. {{Webarchive|url=https://web.archive.org/web/20050526092120/http://www.findarticles.com/p/articles/mi_m0WUB/is_1999_July_5/ai_55071818 |date=2005-05-26 }}</ref> and is available as an informational {{IETF RFC|2516}}.

In the world of DSL, PPP is commonly understood to be running on top of [[Asynchronous Transfer Mode|ATM]] (as PPPoA) with ATM as the underlying Layer 2 protocol and a version of DSL the Layer 1 protocol, although no such limitation exists in the PPP protocol itself. 

Other usage scenarios are sometimes distinguished by tacking as a suffix another underlying protocol. For example, PPPoEoE, when the transport is Ethernet itself, as in the case of [[Metro Ethernet]] networks. (In this notation, the original use of PPPoE would be labeled PPPoEoA, although it should not be confused with [[PPPoA]], which has a different encapsulation of the PPP protocol.)

PPPoE has been described in some books as a "[[layer 2.5]]" protocol,<ref name="GoldenDedieu2007">{{cite book|author1=Philip Golden|author2=Hervé Dedieu|author3=Krista S. Jacobsen|title=Implementation and Applications of DSL Technology|url=https://books.google.com/books?id=Jjkd74jY47oC&pg=PA479|year=2007|publisher=Taylor & Francis|isbn=978-1-4200-1307-8|page=479}}</ref><ref name="Beck2005"/> in some rudimentary sense similar to [[MPLS]] because it can be used to distinguish different IP flows sharing an Ethernet infrastructure, although the lack of PPPoE switches making routing decisions based on PPPoE headers limits applicability in that respect.<ref name="Beck2005">{{cite book|author=Michael Beck|title=Ethernet in the First Mile : The IEEE 802.3ah EFM Standard|year=2005|publisher=McGraw Hill Professional|isbn=978-0-07-146991-3|page=27}}</ref>

==Original rationale==

In late 1998, the DSL service model had yet to reach the large scale that would bring prices down to household levels.  ADSL technology had been proposed a decade earlier.<ref>{{cite web |title= Method and apparatus for wideband transmission of digital signals between, for example, a telephone central office and customer premises |author1=Richard D. Gitlin |author2=Sailesh K. Rao |author3=Jean-Jacques Werner |author4=Nicholas Zervos |work= US Patent 4,924,492 |url= https://patents.google.com/patent/US4924492| date= 8 May 1990 }}</ref>  Potential [[Redback Networks|equipment vendors]] and [[UUNET|carriers]] alike recognized that broadband such as [[cable modem]] or [[DSL]] would eventually replace [[dialup]] service, but the hardware (both customer premises and [[Local exchange carrier|LEC]]) faced a significant [[economies of scale|low-quantity]] [[barriers to entry|cost barrier]].  Initial estimates for low-quantity deployment of DSL showed costs in the {{currency|300–500|USD|linked=no|passthrough=yes}} ({{currency|{{Inflation|US|300|1998}}–{{Inflation|US|500|1998}}|USD|linked=no|passthrough=yes}} in {{Inflation/year|US}}) range for a DSL modem and {{currency|300|USD|linked=no}}/month access fee from the telco,{{Citation needed|date=December 2011}} which was well beyond what a home user would pay.  Thus the initial focus was on [[Small office/home office|small and home business]] customers for whom a ~{{val|1.5|u=Mbit|up=s}} [[Digital Signal 1|T1 line]] (at the time {{currency|800–1500|USD|linked=no|passthrough=yes}} per month) was not economical, but who needed more than dialup or [[ISDN]] could deliver. If enough of these customers paved the way, quantities would drive the prices down to where the home-use dialup user might be interested.

===Different usage profile===
The problem was that small business customers had a different usage profile than a home-use dialup user, including:
* Connecting an entire LAN to the Internet;
* Providing services on a local LAN accessible from the far side of the connection;
* Simultaneous access to multiple external data sources, such as a company VPN and a general purpose ISP;
* Continuous usage throughout the workday, or even around the clock.

These requirements didn't lend themselves to the connection establishment lag of a dial-up process nor its one-computer-to-one-ISP model, nor even the many-to-one that [[Network address translation|NAT]] plus dial-up provided. A new model was required.

PPPoE is used mainly either:
* with PPPoE-speaking Internet [[DSL]] services where a PPPoE-speaking [[modem]]-[[Router (computing)|router]] ([[residential gateway]]) connects to the DSL service. Here both ISP and modem-router need to speak PPPoE. (Note that in this case, the PPPoE-over-DSL side of things is occasionally referred to as ''PPPoEoA'', for ‘PPPoE over [[Asynchronous Transfer Mode|ATM]]’.)
* or when a PPPoE-speaking ''DSL modem'' is connected to a PPPoE-speaking Ethernet-only router using an Ethernet cable.

===Time to market: simpler is better===
One problem with creating a completely new protocol to fill these needs was time.  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,<ref name="Partners">{{cite news|date=5 October 1998 |work=[[Business Wire]]|title=TouchWave Partners With Telogy Networks For VoIP Embedded Communications Software|access-date=16 December 2008|url=http://findarticles.com/p/articles/mi_m0EIN/is_/ai_53056379}}{{dead link|date=December 2013}}</ref> and [[L2TP]] was also in development, but 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.

====Reuse existing software stacks====
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.  Essentially all operating systems at the time had a PPP stack, and the design of PPPoE allowed for a simple wrapper/shim to allow the encapsulation of PPP frames inside Ethernet frames.{{citation needed|date=January 2017}}

====Simplify hardware requirements====
Competing WAN technologies (T1, ISDN) required a [[router (computing)|router]] on the customer premises. PPPoE used a different Ethernet frame type, which allowed the DSL hardware to function as simply a [[Network bridge|bridge]], passing some frames to the WAN and ignoring the others.  Implementation of such a bridge is multiple orders of magnitude simpler than a router.

====Informational RFC====
RFC 2516 was initially released as an [[Request for Comments#Informational|informational]] (rather than [[Internet standards|standards-track]]) RFC for the same reason: the adoption period for a standards-track RFC was prohibitively long.

==Modern-day use-cases==
{{unreferenced section|date=July 2022}}
Around 2000, the PPPoE protocol was used either (i) to connect a DSL modem to a computer or router, displacing the earlier method of using [[USB]], or (ii) the PPP+PPPoE trio of protocol headers was used to connect a router to a network node, a protocol converter, somewhat further upstream belonging either to the ISP or to a wholesale long-distance carrier who in turn connects to the ISP’s IP networks and then to the internet.

The first use-case, router-to-modem connection, involving so-called ‘PPPoEoE’ (the PPPoE protocol trio over a physical Ethernet LAN), is still very much in use today for connecting modems to routers if PPP is used.

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. However since PPP remains popular with some ISPs either as a tunnelling protocol, needed where an ISP uses a wholesale access carrier/reseller or because the features of PPP are desired, or both.

As mentioned earlier, strangely, Ethernet MAC ''headers ''are in fact sometimes found in use with PPPoE headers even when the Ethernet protocol is not in use, not physically present on an Ethernet network. This seems to serve no purpose apart from adding further unnecessary header overhead, so-called ''[[Software bloat|bloat]]''. For example in the case, discussed below, of [[PPPoEoA]], where there was no physical Ethernet, only [[Asynchronous Transfer Mode|ATM]], not only an unnecessary Ethernet MAC layer of header overhead was added but also an additional Ethernet adaptation layer too to make Ethernet fit on top of ATM.

In the second use-case, these additional protocol headers add a serious amount of bloat and so harm performance by a small amount.

In the second use case, the use of PPP+PPPoE+Ethernet MAC extends to a variable distance upstream. It may be confined to the ‘[[Last mile (telecommunications)|first mile]]’: a copper [[twisted pair]] in [[ADSL]] or [[VDSL2]]/[[FTTC]] involving modems and no further, or it may also be used further upstream extending to a BRAS ‘Broadband Remote Access Server’ or ‘access concentrator’ which may or may not handle login but will certainly be a protocol converter of some sort. In one example case PPPoE extends upstream to and terminates at such a node operated by a wholesale carrier which converts to the [[L2TP]] tunnelling protocol which tunnels to the ISP’s IP [[Point of presence|POP]]s (‘point of presence’).

==Stages==
The PPPoE has two distinct stages:

===PPPoE discovery===
Since traditional PPP connections are established between two end points over a serial link or over an ATM virtual circuit that has already been established during dial-up, all PPP frames sent on the wire are sure to reach the other end. But Ethernet networks are multi-access where each node in the network can access every other node. An Ethernet frame contains the hardware address of the destination node ([[MAC address]]). This helps the frame reach the intended destination.

Hence before exchanging PPP control packets to establish the connection over Ethernet, the MAC addresses of the two end points should be known to each other so that they can be encoded in these control packets. The PPPoE Discovery stage does exactly this. It also helps establish a Session ID that can be used for further exchange of packets, and is also used to indicate termination of the session.

PPPoE discovery packets are carried in Ethernet frames with [[EtherType]] set to 0x8863.

===PPP session===
Once the MAC address of the peer is known and a session has been established, the session stage will start. In this stage, chunks of PPP data are encapsulated in PPPoE packets and sent to the other peer. The first session packets will negotiate the PPP session as usual, and after that most session packets will contain PPP data chunks.

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.

==PPPoE discovery (PPPoED) ==
Although traditional PPP is a [[peer-to-peer]] protocol, PPPoE is inherently a [[Client–server model|client-server]] relationship since multiple hosts can connect to a service provider over a single physical connection.

The discovery process consists of four steps between the host computer which acts as the client and the access concentrator at the Internet service provider's end acts as the server.  They are outlined below.  The fifth and last step is the way to close an existing session.

===Client to server: Initiation (PADI)===
<!-- [[Padi]] links to this section -->

'''PADI''' stands for PPPoE Active Discovery Initiation.<ref name="tools.ietf.org">{{cite journal|url=https://tools.ietf.org/html/rfc2516.html|title=A Method for Transmitting PPP Over Ethernet (PPPoE)|first1=L.|last1=Mamakos|first2=D.|last2=Simone|first3=R.|last3=Wheeler|first4=D.|last4=Carrel|first5=J.|last5=Evarts|first6=K.|last6=Lidl|website=tools.ietf.org|date=February 1999|doi=10.17487/RFC2516 |access-date=26 March 2019|url-access=subscription}}</ref>

If a user wants to "dial up" to the Internet using DSL, then their computer first must find the DSL access concentrator (DSL-AC) at the user's [[Internet service provider]]'s [[point of presence]] (POP). Communication over Ethernet is only possible via [[MAC address]]es.  As the computer does not know the MAC address of the DSL-AC, it sends out a PADI packet via an Ethernet [[Broadcasting (networking)|broadcast]] (MAC: ff:ff:ff:ff:ff:ff). This PADI packet contains the MAC address of the computer sending it.

Example of a PADI-packet:

<pre>Frame 1 (44 bytes on wire, 44 bytes captured)
Ethernet II, Src: 00:50:da:42:d7:df, Dst: ff:ff:ff:ff:ff:ff
PPP-over-Ethernet Discovery
  Version: 1
  Type 1
  Code Active Discovery Initiation (PADI)
  Session ID: 0000
  Payload Length: 24
PPPoE Tags
  Tag: Service-Name
  Tag: Host-Uniq
    Binary Data: (16 bytes)
</pre>
''Src.'' (=source) holds the MAC address of the computer sending the PADI.<br />
''Dst.'' (=destination) is the Ethernet broadcast address. <br />
The PADI packet can be received by more than one DSL-AC.
Only DSL-AC equipment that can serve the "Service-Name" tag should reply.

===Server to client: Offer (PADO)===
'''PADO''' stands for PPPoE Active Discovery Offer.<ref name="tools.ietf.org"/>

Once the user's computer has sent the PADI packet, the DSL-AC replies with a PADO packet, using the MAC address supplied in the PADI. The PADO packet contains the MAC address of the DSL-AC, its name (e.g. LEIX11-erx for the T-Com DSL-AC in [[Leipzig]]) and the name of the service. If more than one POP's DSL-AC replies with a PADO packet, the user's computer selects the DSL-AC for a particular POP using the supplied name or service.

Here is an example of a PADO packet:

<pre>Frame 2 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:0e:40:7b:f3:8a, Dst: 00:50:da:42:d7:df
PPP-over-Ethernet Discovery
  Version: 1
  Type 1
  Code Active Discovery Offer (PADO)
  Session ID: 0000
  Payload Length: 36
PPPoE Tags
  Tag: AC-Name
    String Data: lpzbr001
  Tag: Host-Uniq
    Binary Data: (16 bytes)
</pre>
''AC-Name -> String data'' holds the AC name, in this case “lpzbr001” (the Arcor DSL-AC in Leipzig)<br />
''Src.'' holds the MAC address of the DSL-AC.<br />
The MAC address of the DSL-AC also reveals the manufacturer of the DSL-AC (in this case [[Nortel Networks]]).

===Client to server: request (PADR)===
'''PADR''' stands for PPPoE active discovery request.<ref name="tools.ietf.org"/>

A PADR packet is sent by the user's computer to the DSL-AC following receipt of an acceptable PADO packet from the DSL-AC. It confirms acceptance of the offer of a PPPoE connection made by the DSL-AC issuing the PADO packet.

===Server to client: session-confirmation (PADS)===
'''PADS''' stands for PPPoE Active Discovery Session-confirmation.<ref name="tools.ietf.org"/>

The PADR packet above is confirmed by the DSL-AC with a PADS packet, and a Session ID is given out with it. The connection with the DSL-AC for that POP has now been fully established.

===Either end to other end: termination (PADT)===
'''PADT''' stands for PPPoE Active Discovery Termination.<ref name="tools.ietf.org"/> This packet terminates the connection to the POP. It may be sent either from the user's computer or from the DSL-AC.

==Protocol overhead==
PPPoE is used to connect a PC or a [[router (computing)|router]] to a [[modem]] via an Ethernet link and it can also be used in [[Internet access]] over [[DSL]] on a telephone line in the ''PPPoE over ATM'' (PPPoEoA) over [[ADSL]] [[protocol stack]].
PPPoE over [[Asynchronous Transfer Mode|ATM]] has the highest overhead of the popular DSL delivery methods, when compared with for example PPPoA (RFC 2364).<ref name="wand.cs.waikato.ac.nz">Dirk Van Aken, Sascha Peckelbeen [http://wand.cs.waikato.ac.nz/~513/2006/readings/adsl-2.pdf Encapsulation Overhead(s) in ADSL Access Networks] {{Webarchive|url=https://web.archive.org/web/20210412055017/http://wand.cs.waikato.ac.nz/~513/2006/readings/adsl-2.pdf |date=12 April 2021 }}, June 2003</ref><ref name="RFC 2364">{{cite journal|url=https://tools.ietf.org/html/rfc2364.html|title=PPP Over AAL5|first1=Manu|last1=Kaycee|first2=George|last2=Gross|first3=Andrew|last3=Malis|first4=John|last4=Stephens|first5=Arthur|last5=Lin|website=tools.ietf.org|date=July 1998|doi=10.17487/RFC2364 |access-date=26 March 2019|url-access=subscription}}</ref><ref name="RFC 2684">{{cite journal|url=https://tools.ietf.org/html/rfc2684.html|title=Multiprotocol Encapsulation over ATM Adaptation Layer 5|first1=Dan|last1=Grossman|first2=Juha|last2=Heinanen|website=tools.ietf.org|date=September 1999|doi=10.17487/RFC2684 |access-date=26 March 2019|doi-access=|url-access=subscription}}</ref><ref name="Simon Farnsworth article">{{cite web|url=http://blog.farnz.org.uk/2010/02/on-pppoa-pppoe-atm-and-adsl.html|title=Simon Farnsworth article|website=farnz.org.uk|access-date=26 March 2019}}</ref>

===Use with DSL – PPPoE over ATM (PPPoEoA)===
The amount of overhead added by PPPoEoA on a DSL link depends on the packet size because of (i) the absorbing effect of ATM cell-padding (discussed below), which completely cancels out additional overhead of PPPoEoA in some cases, (ii) PPPoEoA + [[AAL5]] overhead which can cause an entire additional 53-byte ATM cell to be required, and (iii) in the case of IP packets, PPPoE overhead added to packets that are near maximum length (''‘[[Maximum transmission unit|MRU]]’'') may cause [[IP fragmentation]], which also involves the first two considerations for both of the resulting IP fragments.<ref>[http://www.technicolorbroadbandpartner.com/getfile.php?id=525 Encapsulation Overhead(s) in ADSL Access Networks.]{{Dead link|date=December 2018 |bot=InternetArchiveBot |fix-attempted=yes }}</ref> 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).<ref name="wand.cs.waikato.ac.nz"/> This overhead is that obtained when using the LLC header option described in RFC 2684 for PPPoEoA.<ref name="RFC 2684"/><ref name="Simon Farnsworth article"/>

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. (In fact, just simply 10 bytes = 2 bytes for PPP + zero for RFC 2364 + 8 (AAL5 CPCS).)<ref name="RFC 2364"/><ref name="Simon Farnsworth article"/>

This figure of 44 bytes AAL5 payload overhead can be reduced in two ways: (i) by choosing the RFC 2684 option of discarding the 4-byte Ethernet MAC FCS, which reduces the figure of 18 bytes above to 14, and  (ii) by using the RFC 2684 VC-MUX option, whose overhead contribution is a mere 2 bytes compared with the 10 byte overhead of the LLC alternative. It turns out that this overhead reduction can be a valuable efficiency improvement. Using VC-MUX instead of LLC, the ATM payload overhead is either 32 bytes (without Ethernet FCS) or 36 bytes (with FCS).<ref name="wand.cs.waikato.ac.nz"/><ref name="RFC 2684"/>

ATM AAL5 requires that an 8-byte-long ‘CPCS’ trailer must always be present at the very end of the final cell (‘right justified’) of the run of ATM cells that make up the AAL5 payload packet. In the LLC case, the total ATM payload overhead is 2 + 6 + 18 + 10 + 8 = 44 bytes if the Ethernet MAC FCS is present, or 2 + 6 + 14 + 10 + 8 = 40 bytes with no FCS. In the more efficient VC-MUX case the ATM payload overhead is 2 + 6 + 18 + 2 + 8 = 36 bytes (with FCS), or 2 + 6 + 14 + 2 + 8 = '''32 bytes''' (no FCS).

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). This is because ATM cells are fixed length with a payload capacity of 48 bytes, and adding a greater extra amount of AAL5 payload due to additional headers may require one more whole ATM cell to be sent containing the excess. The last one or two ATM cells contain padding bytes as required to ensure that each cell's payload is 48 bytes long.<ref name="wand.cs.waikato.ac.nz"/><ref name="RFC 2684"/>

An example: In the case of a 1500-byte IP packet sent over AAL5/ATM with PPPoEoA and RFC2684-LLC, neglecting final cell padding for the moment, one starts with 1500 + 2 + 6 + 18 + 10 + 8 (AAL5 CPCS trailer) = 1544 bytes if the Ethernet FCS is present, or else + 2 + 6 + 14 + 10 + 8 = 40 bytes with no FCS. To send 1544 bytes over ATM requires 33 48-byte ATM cells, since the available payload capacity of 32 cells × 48 bytes per cell = 1536 bytes is not quite enough. Compare this to the case of PPP + PPPoA which at 1500 + 2 (PPP) + 0 (PPPoA: RFC 2364 VC-MUX) + 8 (CPCS trailer) = 1510 bytes fits in 32 cells. So the real cost of choosing PPPoEoA plus RFC2684-LLC for 1500-byte IP packets is one additional ATM cell per IP packet, a ratio of 33:32.<ref name="wand.cs.waikato.ac.nz"/><ref name="RFC 2364"/><ref name="RFC 2684"/> So for 1500 byte packets, PPPoEoA with LLC is ~3.125% slower than PPPoA or optimal choices of PPPoEoA header options.

For some packet lengths the true additional effective DSL overhead due to choosing PPPoEoA compared with PPPoA will be zero if the extra header overhead is not enough to need an additional ATM cell at that particular packet length. For example, a 1492 byte long packet sent with PPP + PPPoEoA using RFC2684-LLC plus FCS gives us a total ATM payload of 1492 + 44 = 1536 bytes = 32 cells exactly, and the overhead in this special case is no greater than if we were using the header-efficient PPPoA protocol, which would require 1492 + 2 + 0 + 8 = 1502 bytes ATM payload = 32 cells also.<ref name="wand.cs.waikato.ac.nz"/><ref name="RFC 2684"/> The case where the packet length is 1492 represents the optimum efficiency for PPPoEoA with RFC2684-LLC in ratio terms, unless even longer packets are allowed.

Using PPPoEoA with the RFC2684 VC-MUX header option is always much more efficient than the LLC option, since the ATM overhead, as mentioned earlier, is only 32 or 36 bytes (depending on whether this is without or with the Ethernet FCS option in PPPoEoA) so that a 1500 byte long packet including all overheads of PPP + PPPoEoA using VC-MUX equates to a total 1500 + 36 = 1536 bytes ATM payload if the FCS is present = 32 ATM cells exactly, thus saving an entire ATM cell.<ref name="wand.cs.waikato.ac.nz"/><ref name="RFC 2684"/>

With short packets, the longer the header overheads the greater the likelihood of generating an additional ATM cell. A worst case might be sending 3 ATM cells instead of two because of a 44 byte header overhead compared with a 10 byte header overhead, so 50% more time taken to transmit the data. For example, a TCP ACK packet over IPv6 is 60 bytes long, and with overhead of 40 or 44 bytes for PPPoEoA + LLC this requires three 48 byte ATM cells’ payloads. As a comparison, PPPoA with overheads of 10 bytes so 70 bytes total fits into two cells. So the extra cost of choosing PPPoE/LLC over PPPoA is 50% extra data sent. PPPoEoA + VC-MUX would be fine though: with 32 or 36 byte overhead, our IP packet still fits in two cells.

In all cases the most efficient option for ATM-based ADSL internet access is to choose PPPoA (RFC2364) VC-MUX. However, if PPPoEoA is required, then the best choice is always to use VC-MUX (as opposed to LLC) with no Ethernet FCS, giving an ATM payload overhead of '''32 bytes''' = 2 bytes (for PPP) + 6 (for PPPoE) + 14 (Ethernet MAC, no FCS) + 2 (RFC 2684 VC-MUX) + 8 (AAL5 CPCS trailer).

Unfortunately some DSL services require the use of wasteful LLC headers with PPPoE and do not allow the more efficient VC-MUX option. In that case, using a reduced packet length, such as enforcing a maximum MTU of 1492 regains efficiency with long packets even with LLC headers and, as mentioned earlier, in that case no extra wasteful ATM cell is generated.

===Overhead on Ethernet===
On an Ethernet LAN, the overhead for PPP + PPPoE is a fixed 2 + 6 = '''8 bytes''', unless IP fragmentation is produced.

==MTU/MRU==
When a PPPoE-speaking DSL modem sends or receives Ethernet frames containing PPP + PPPoE payload ''across the Ethernet link to a router'' (or PPPoE-speaking single PC), PPP + PPPoE contributes an additional overhead of 8 bytes = 2 (PPP) + 6 (PPPoE) included within the payload of each Ethernet frame. This added overhead can mean that a reduced maximum length limit (so-called ''‘[[Maximum transmission unit|MTU]]’'' or ''‘[[Maximum transmission unit|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. Some devices support RFC 4638, which allows negotiation for the use of non-standard Ethernet frames with a 1508-byte Ethernet payload, sometimes called ‘baby [[jumbo frames]]’, so allowing a full 1500-byte PPPoE payload. This capability is advantageous for many users in cases where companies receiving IP packets have (incorrectly) chosen to block all [[Internet Control Message Protocol|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.

==PPPoE-to-PPPoA converting ADSL modem==
The following diagram shows a scenario where an Ethernet-connected ADSL modem acts as a PPPoE-to-[[Point-to-Point Protocol over ATM|PPPoA]] protocol converter and the service provider offers a PPPoA service and does not understand PPPoE. There is no PPPoEoA in this protocol chain. This is an optimally protocol-efficient design for a separate ADSL modem connected to a router by Ethernet.

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). Here it is not concerned with the mechanism employed by an ISP to offer broadband services.

The Draytek Vigor 110, 120 and 130 modems work in this way.

When transmitting packets bound for the Internet, the PPPoE-speaking Ethernet router sends Ethernet frames to the (also PPPoE-speaking) DSL modem. The modem extracts PPP frames from within the received PPPoE frames, and sends the PPP frames onwards to the DSLAM by encapsulating them according to RFC 2364 (PPPoA), thus converting PPPoE into PPPoA.

:{| border="0" cellspacing="3" style="float:center;padding-left:15px"
|+ '''DSL Internet access architecture'''
|-  style="vertical-align:bottom; text-align:center; background:#fc9;"
| colspan="2"| '''PC or Gateway'''
| colspan="2"| '''[[DSL modem]]'''
| colspan="2"| '''[[DSLAM]]'''
| colspan="2"| '''Remote access server'''
|| '''(ISP)'''
|-
|  style="vertical-align:bottom; text-align:center; background:#eef;"| ([[Internet Protocol|IP]])
|
|
|
|
|
|
|
|  style="vertical-align:bottom; text-align:center; background:#eef;"| (IP)
|-
|  style="vertical-align:bottom; text-align:center; background:#eef;"| Ethernet
|  style="vertical-align:bottom; text-align:center; background:#eef;"| PPP
|
|
|
|
|  style="vertical-align:bottom; text-align:center; background:#eef;"| PPP
|  style="vertical-align:bottom; text-align:center; background:#eef;"| PPP
|  style="vertical-align:bottom; text-align:center; background:#eef;"| PPP
|-
|
|  style="vertical-align:bottom; text-align:center; background:#99f;"| '''PPPoE'''
|  style="vertical-align:bottom; text-align:center; background:#99f;"| '''PPPoE'''
|  style="vertical-align:bottom; text-align:center; background:#99f;"| '''PPPoA'''
|
|
|  style="vertical-align:bottom; text-align:center; background:#99f;"| '''PPPoA'''
|  style="vertical-align:bottom; text-align:center; background:#eef;"| L2TP
|  style="vertical-align:bottom; text-align:center; background:#eef;"| L2TP
|-
|
|  style="vertical-align:bottom; text-align:center; background:#eef;"| Ethernet
|  style="vertical-align:bottom; text-align:center; background:#eef;"| Ethernet
|  style="vertical-align:bottom; text-align:center; background:#eef;"| AAL5
|  style="vertical-align:bottom; text-align:center; background:#eef;"| AAL5
|  style="vertical-align:bottom; text-align:center; background:#eef;"| backbone
|  style="vertical-align:bottom; text-align:center; background:#eef;"| backbone
|  style="vertical-align:bottom; text-align:center; background:#eef;"| IP
|  style="vertical-align:bottom; text-align:center; background:#eef;"| IP
|-
|
|
|
|  style="vertical-align:bottom; text-align:center; background:#eef;"| ATM
|  style="vertical-align:bottom; text-align:center; background:#eef;"| ATM
|-
|
|
|
|  style="vertical-align:bottom; text-align:center; background:#eef;"| [[DSL]]
|  style="vertical-align:bottom; text-align:center; background:#eef;"| DSL
|}

On the diagram, the area shown as ‘backbone’ could also be ATM on older networks, however its architecture is service provider-dependent. On a more detailed, more service-provider specific diagram there would be additional table cells in this area.

==Quirks==
Since the point-to-point connection established has a [[MTU (networking)|MTU]] lower than that of standard Ethernet (typically 1492 vs Ethernet's 1500), it can sometimes cause problems when [[Path MTU Discovery]] is defeated by poorly configured [[Firewall (networking)|firewall]]s. Although higher MTUs are becoming more common in providers' networks, usually the workaround is to use TCP MSS (Maximum Segment Size) "clamping" or "rewrite", whereby the access concentrator rewrites the MSS to ensure TCP peers send smaller datagrams. Although TCP MSS clamping solves the MTU issue for TCP, other protocols such as ICMP and UDP may still be affected.

RFC 4638 allows PPPoE devices to negotiate an MTU of greater than 1492 if the underlying Ethernet layer is capable of [[jumbo frames]].

Some vendors ([[Cisco Systems|Cisco]]<ref name="cisco.com">{{Cite web | url=http://www.cisco.com/en/US/docs/ios/bbdsl/configuration/guide/bba_understanding.pdf | title=Understanding Broadband Access Aggregation | date=2005-05-02 | publisher=[[Cisco | Cisco Systems]]}}</ref> and [[Juniper Networks|Juniper]],{{citation needed|date=December 2013}} for example) distinguish PPPoE[oA] from PPPoEoE (PPPoE over Ethernet), which is PPPoE running directly over Ethernet or other [[IEEE 802]] networks or over Ethernet [[Bridging (networking)|bridged]] over [[Asynchronous Transfer Mode|ATM]], in order to distinguish it from PPPoEoA (PPPoE over ATM), which is PPPoE running over an ATM virtual circuit using RFC 2684 and [[Subnetwork Access Protocol|SNAP]] encapsulation of PPPoE.{{citation needed|date=December 2013}} (PPPoEoA is not the same as [[Point-to-Point Protocol over ATM]] (PPPoA), which doesn't use SNAP).

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. This encapsulation method is generally found in Metro Ethernet or Ethernet digital subscriber line access multiplexer (DSLAM) environments. The common deployment model is that this encapsulation method is typically found in multi-tenant buildings or hotels. By delivering Ethernet to the subscriber, the available bandwidth is much more abundant and the ease of further service delivery is increased."<ref name="cisco.com"/>

It is possible to find DSL modems, such as the Draytek Vigor 120, where PPPoE is confined to the Ethernet link between a DSL modem and a partnering router,  and the ISP does not speak PPPoE at all (but rather [[PPPoA]]).<ref>{{Cite web |url=https://www.draytek.com/index.php?option=com_k2&view=item&layout=item&id=2405&Itemid=451&lang=en |title=Vigor120 - DrayTek Corp |access-date=2014-02-10 |archive-url=https://web.archive.org/web/20140223002531/https://www.draytek.com/index.php?option=com_k2&view=item&layout=item&id=2405&Itemid=451&lang=en#overview |archive-date=2014-02-23 |url-status=dead }}</ref>

== Post-DSL uses and some alternatives in these contexts ==
A certain method of using PPPoE in conjunction with [[GPON]] (which involves creating a [[VLAN]] via [[OMCI]]) has been patented by [[ZTE]].<ref>{{cite web|url=https://patents.google.com/patent/EP2560407A1/en|title=Gigabit-capable passive optical network system and point-to-point protocol over ehternet configuration method implemented thereby|website=google.com|access-date=26 March 2019}}</ref>

PPPoE over GPON is reportedly used by retail service providers such as [[Internode (ISP)|Internode]] of Australia's [[National Broadband Network]],<ref>{{Cite web|url=https://www.internode.on.net/support/guides/internet_access/nbn/fttp/|archiveurl=https://web.archive.org/web/20130913035546/http://www.internode.on.net/support/guides/internet_access/fibre_to_the_home/fritz%21box_7270/|url-status=dead |title=Internode :: Support :: Guides :: Internet Access :: NBN :: FTTP|archivedate=13 September 2013|website=www.internode.on.net}}</ref> [[Orange S.A.|Orange]] of France,<ref>{{cite web|url=https://community.tp-link.com/en/news/17?71785-ArcherC7-Firmware-improvements|title=TP-Link new Community is officially launched！ - TP-Link Community|website=community.tp-link.com|access-date=26 March 2019|url-status=dead|archive-date=26 March 2019|archive-url=https://web.archive.org/web/20190326095033/https://community.tp-link.com/en/news/17%3F71785-ArcherC7-Firmware-improvements}}{{failed verification|reason=broken link but doesn't look like this was a reliable source.|date=February 2022}}</ref> [[Antel]] of Uruguay,<ref>{{cite web |title=Introducción Básica a Wi-Fi |url=https://wse-prod.antel.com.uy/LEXW/servlet/com.antel.lex.adownload?adyxx70kJBO8Kd661phVeTKCSV2GlzSjbnbDSeH7Iac%3D |website=Antel |publisher=Antel |language=es}}</ref> the Philippines' [[Globe Telecom]]<ref>{{cite web|url=https://www.youtube.com/watch?v=9crvbWQrEn4| archive-url=https://web.archive.org/web/20140608160809/http://www.youtube.com/watch?v=9crvbWQrEn4| archive-date=2014-06-08 | url-status=dead|title=YouTube|website=www.youtube.com|access-date=26 March 2019}}{{failed verification|reason=archive not working well enough for verification|date=February 2022}}</ref> and Italy's Aruba FTTH<ref>{{Cite web |title=Configurazione dei router e modem ADSL {{!}} Guide Aruba |url=https://guide.aruba.it/connettivita/fibra/configurazione-del-servizio/configurazione-router-e-modem-fibra.aspx |access-date=2022-03-10 |website=guide.aruba.it}}</ref> on [[Open Fiber|OpenFiber]] public GPON networks.

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]. This covers PPP over Ethernet (PPPoE, defined in [RFC2516]) or IP over Ethernet (IPoE). The protocol encapsulation on GPON is always IPoE."<ref>{{cite journal|url=https://datatracker.ietf.org/doc/rfc6934/?include_text=1|title=RFC 6934 - Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs)|website=datatracker.ietf.org|date=June 2013|access-date=26 March 2019|last1=Bitar|first1=Nabil N.|last2=Wadhwa|first2=Sanjay|last3=Haag|first3=Thomas|last4=Hongyu|first4=Li}}</ref>

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]].<ref>{{cite book|author1=Dave Hood  |author2=Elmar Trojer |name-list-style=amp |title=Gigabit-capable Passive Optical Networks|year=2012|publisher=John Wiley & Sons|isbn=978-1-118-15558-5|page=200}}</ref> 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. (The ONU is supposed snoop [[Extensible Authentication Protocol|EAP]]-encapsulated [[RADIUS]] messages in this scenario and determine if the authentication was successful or not.)<ref>{{cite book|author1=Dave Hood  |author2=Elmar Trojer |name-list-style=amp |title=Gigabit-capable Passive Optical Networks|year=2012|publisher=John Wiley & Sons|isbn=978-1-118-15558-5|page=207 and 274–275}}</ref> There is some modicum support for PPPoE specified in the OMCI standards<!-- alas the book doesn't exactly specify in which one-->, but only in terms of the ONU being able to filter and add VLAN tags for traffic based on its encapsulation (and other parameters), which includes PPPoE among the protocols that ONU must be able to discern.<ref>{{cite book|author1=Dave Hood  |author2=Elmar Trojer |name-list-style=amp |title=Gigabit-capable Passive Optical Networks|year=2012|publisher=John Wiley & Sons|isbn=978-1-118-15558-5|page=261 and 271}}</ref>

The [[Broadband Forum]]'s TR-200 "Using [[Ethernet passive optical network|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."<ref>{{Cite web | title=Broadband Forum Published Resources - Resources - BBF Wiki | url=http://www.broadband-forum.org/technical/download/TR-200.pdf | access-date=2025-03-31 | website=www.broadband-forum.org}}</ref>

A book on [[Ethernet in the first mile]] notes that DHCP can obviously be used instead of PPPoE to configure a host for an IP session, although it points out that DHCP is not a complete replacement for PPPoE if some encapsulation is also desired (although VLAN bridges can fulfill this function) and that furthermore, DHCP does not provide (subscriber) authentication, suggesting that IEEE 802.1X is also needed for a "complete solution" without PPPoE.<ref name="Beck2005b">{{cite book|author=Michael Beck|title=Ethernet in the First Mile : The IEEE 802.3ah EFM Standard|year=2005|publisher=McGraw Hill Professional|isbn=978-0-07-146991-3|page=241}}</ref> (This book assumes that PPPoE is leveraged for other features of PPP besides encapsulation, including [[Internet Protocol Control Protocol|IPCP]] for host configuration, and [[Password Authentication Protocol|PAP]] or [[Challenge-Handshake Authentication Protocol|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.<ref name="Carcelle2009">{{cite book|author=Xavier Carcelle|title=Power Line Communications in Practice|url=https://books.google.com/books?id=2cvj-oFvfE0C&pg=PA235|year=2009|publisher=Artech House|isbn=978-1-59693-336-1|page=235}}</ref>

PPPoE is widely used on WAN lines, including [[FTTx]]. Many FTTx residential gateway provided by ISP has integrated the routing functions.

==See also==
* [[Multiprotocol Encapsulation over ATM]]
* [[Point-to-Point Protocol daemon]]
* [[Point-to-Point Tunneling Protocol]]
* [[Point-to-Point Protocol over ATM]] (PPPoA)
* [[PPPoX|Point-to-Point Protocol over X]] (PPPoX)

==References==
{{Reflist|30em}}

==External links==
* {{IETF RFC|2516|link=no}} - A Method for Transmitting PPP Over Ethernet (PPPoE)
* {{IETF RFC|3817|link=no}} - [[Layer 2 Tunneling Protocol]] (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE)
* {{IETF RFC|4638|link=no}} - Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)
* {{IETF RFC|4938|link=no}} - PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics
* [https://patents.google.com/patent/US6891825 US Patent 6891825] - Method and system of providing multi-user access to a packet switched network
* [https://www.broadband-forum.org/technical/download/TR-043.pdf TR-043] - Protocols at the U Interface for Accessing Data Networks using ATM/DSL, Issue 1.0, August 2001
{{Use dmy dates|date=July 2020}}

[[Category:1999 in technology]]
[[Category:Tunneling protocols]]
[[Category:Logical link control]]
[[Category:Wide area networks]]
[[Category:Ethernet]]