+ PPPoE and TCP/IP protocol stack Application FTP SMTP HTTP ... DNS ... Transport TCP UDP Internet IP IPv6 Network access PPP PPPoE Ethernet
The Point-to-Point Protocol over Ethernet (PPPoE) is a network protocol for 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 packets over the DSL connection to the Internet service provider's (ISP's) 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 compression." Typical use of PPPoE involves leveraging the PPP facilities for authenticating the user with a username and password, via PAP or via CHAP. PAP was dominant in 2007 but service providers have been transitioning to the more secure CHAP , because PAP is a plain-text protocol. Around 2000, PPPoE was also starting to become a replacement method for talking to a modem connected to a computer or 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 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, Linux to Mac OS X.) More recently, 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) and is available as an informational .
In the world of DSL, PPP is commonly understood to be running on top of 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, 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.
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. 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. Initial estimates for low-quantity deployment of DSL showed costs in the ( in ) range for a DSL modem and /month access fee from the telco, which was well beyond what a home user would pay. Thus the initial focus was on small and home business customers for whom a ~ T1 line (at the time 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 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 (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 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, 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.
Simplify hardware requirements Competing WAN technologies (T1, ISDN) required a router on the customer premises. PPPoE used a different Ethernet frame type, which allowed the DSL hardware to function as simply a 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 informational (rather than standards-track) RFC for the same reason: the adoption period for a standards-track RFC was prohibitively long.
Modern-day use-cases
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 bloat. For example in the case, discussed below, of PPPoEoA, where there was no physical Ethernet, only 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 ‘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 POPs (‘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 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 ISP'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 stands for PPPoE Active Discovery Initiation.
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 ISP's point of presence (POP). Communication over Ethernet is only possible via MAC addresses. As the computer does not know the MAC address of the DSL-AC, it sends out a PADI packet via an Ethernet 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:
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) Src. (=source) holds the MAC address of the computer sending the PADI. Dst. (=destination) is the Ethernet broadcast address.