Point-to-Point Protocol over Ethernet

{| 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;"| 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;"| DNS

| style="text-align:center; background:#eef;"| ...

| style="text-align:center; background:#feb;"| Transport

| colspan="4" style="text-align:center; background:#eef;"| TCP

| colspan="2" style="text-align:center; background:#eef;"| UDP

| style="text-align:center; background:#feb;"| Internet

| colspan="3" style="text-align:center; background:#eef;"| 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;"| 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 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 the PAP protocol 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. 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,

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:

<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.

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 (‘MRU’) may cause IP fragmentation, which also involves the first two considerations for both of the resulting IP fragments. 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). and Juniper, 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 bridged over ATM, in order to distinguish it from PPPoEoA (PPPoE over ATM), which is PPPoE running over an ATM virtual circuit using RFC 2684 and SNAP encapsulation of PPPoE. (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."

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.

PPPoE over GPON is reportedly used by retail service providers such as Internode of Australia's National Broadband Network, Orange of France, Antel of Uruguay, the Philippines' Globe Telecom and Italy's Aruba FTTH on 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."

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. 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 EAP-encapsulated RADIUS messages in this scenario and determine if the authentication was successful or not.) There is some modicum support for PPPoE specified in the OMCI standards, 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.

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."

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. (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.

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

References

External links

- A Method for Transmitting PPP Over Ethernet (PPPoE)
- Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE)
- Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)
- PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics
US Patent 6891825 - Method and system of providing multi-user access to a packet switched network
TR-043 - Protocols at the U Interface for Accessing Data Networks using ATM/DSL, Issue 1.0, August 2001