Point-to-point protocol over Ethernet

Not to be confused with power over Ethernet.

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 is used mainly with DSL services where individual users connect to the DSL modem over Ethernet and in plain Metro Ethernet networks. It was developed by UUNET, Redback Networks and RouterWare (now Wind River Systems) and is available as an informational RFC 2516.

Ethernet networks are packet-based and have no concept of a connection or circuit and also lack basic security features to protect against IP and MAC conflicts and rogue DHCP servers. By using PPPoE, users can virtually "dial" from one machine to another over an Ethernet network, establish a point to point connection between them and then securely transport data packets over the connection. It is mainly used by telephone companies, since PPPoE is easily integrated with legacy dial-up AAA systems and fits perfectly into the ATM backbones. The protocol also permits very easy unbundling of digital subscriber line access multiplexers (DSLAM) where required by regulators, since the user would simply use a different login into PPP, then the ATM circuit would be routed to the user's ISP. Also pre-paid traffic bucket business models can be created with PPPoE more easily than with DHCP or multiplexing multiple users with different speed tiers or QoS through 1 DSL modem or by creating a different login for each static IP purchased by customers.

Original rationale

In late 1998 the DSL service model had a chicken-and-egg problem. ADSL technology had been proposed a decade earlier. Potential Equipment vendors and carriers alike recognized that broadband such as Cablemodem 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 $300-$500 range for a DSL modem and $300/mo access fee from the telco^{[citation needed]} which was well beyond what a home user would pay. Thus the initial focus was on small & home business customers for whom a T1 line (at the time $800-$1500 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: more like $50 for the modem and $50/mo for the access.

Different usage profile

The problem was that small business customers had a different usage profile than a home-use dialup user, including

1. connecting an entire LAN to the internet
2. providing services on a local LAN accessible from the far side of the connection
3. simultaneous access to multiple external data sources, such as a company VPN and a general purpose ISP
4. continuous usage throughout the workday, or even around the clock

These requirements didn't lend themselves to the connection establishment lag of a dialup process, nor its one-computer-to-one-ISP model, nor even the many-to-one that NAT + dialup provided. A new model was required.

Time to market: simpler is better

A problem with creating a completely new protocol to fill these needs was time. The equipment was available immediately, as was the service, and a whole new protocol stack (Microsoft at the time was advocating fiber-based atm-cells-to-the-desktop, 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.

Reuse existing software stacks

PPPoE hoped to merge the widespread ethernet infrastructure with the ubiquitous PPP protocol, allowing vendors on both sides of the connection to heavily leverage 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 shim at the line-encoding stage to convert from PPP to PPPoE.

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.

Success

PPPoE was initially designed to provide a small LAN with individual independent connections to the internet at large, but also such that the protocol itself would be lightweight enough that it wouldn't impinge on the hoped-for home usage market when it finally arrived. While success on the second matter may be debated (some complain that 8 bytes per packet is too much) PPPoE clearly succeeded in bringing sufficient volume to drive the price for service down to what a home user would pay. It remains the dominant DSL connectivity mechanism as of 2011, more than a decade later.

Looking forward

PPPoE faces a difficult future. MPLS/IP backbones and IP-DSLAMs are considered the norm and the circuit switched family technologies (ATM/PDH) are being called legacy technologies^{[citation needed]}. Pseudowire and VoIP can be used to deal with legacy customers and equipment. PPPoE has the highest overhead DSL delivery method. The amount of overhead added by PPPoE depends on the packet size because PPPoE adds 8 bytes to each packet. If packets are large, say 1492 bytes, the overhead is only 0.54 % ((1500-1492)/1492). If packets are small though, such as the traffic required by certain web applications, VoIP or online games, the overhead can be much greater. As an example, if a specific VoIP connection used a packet size of 60 bytes, a PPPoE connection adds a 15.3 % overhead. ATM, because of its overhead, is also being purged and PPPoE goes out with that. For example, Verizon's FIOS product has converted to using DHCP internet access instead of PPPoE delivery. GPON, an upgrade of BPON, added an alternative to ATM. PPPoE networks face difficulty in adding multicasting and many level of QoS and lowest overhead for highest speeds for IPTV in today's convergence and triple play networks.

How PPPoE fits in the DSL Internet access architecture

The transport protocol used on the telephone network is ATM. The DSL modem encapsulates PPP packets inside ATM cells and sends them over the WAN. There are several encapsulation methods.

PPPoEoA

Ethernet packets containing the PPPoE packets are bridged over ATM (RFC 2684).

DSL Internet access architecture

Host PC	DSL modem		DSLAM		Remote access server
IP					IP
PPP					PPP
PPPoE					PPPoE
Ethernet	Ethernet	Ethernet			Ethernet
		ATM			ATM
		DSL	DSL	backbone	backbone

PPPoE to PPPoA

The PPP frames are extracted from the PPPoE packets and encapsulated in ATM, thus converting PPPoE into PPPoA (RFC 2364).

DSL Internet access architecture

Host PC	DSL modem		DSLAM		Remote access server
IP					IP
PPP					PPP
PPPoE	PPPoE	PPPoA			PPPoA
Ethernet	Ethernet	ATM			ATM
		DSL	DSL	backbone	backbone

PPPoE 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 address 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. In addition it also helps establish a Session ID that can be used for further exchange of packets.

PPP session

Once the MAC address of the peer is known and a session has been established, the Session stage.

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 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 stands for PPPoE Active Discovery Initiation.
If a user wants to dial up to the Internet using DSL, then his 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 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.
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.
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:

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: IpzbrOOl
  Tag: Host-Uniq
    Binary Data: (16 bytes)

AC-Name -> String data holds the AC name, in this case “Ipzbr001” (the Arcor DSL-AC in Leipzig)
Src. holds the MAC address of the DSL-AC.
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.
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.
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.
This packet terminates the connection to the POP. It may be sent either from the user's computer or from the DSL-AC.

Quirks

Since the point to point connection established has a 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 firewalls. Although higher MTUs are becoming more common in providers' networks, usually the fix 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. In practice, this does not present significant issues for residential users since most content is served over TCP.

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 and Juniper, for example) refer to 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).

See also

• Multiprotocol Encapsulation over ATM
• Point-to-Point Protocol daemon
• Point-to-Point Tunneling Protocol
• Point-to-Point Protocol over ATM (PPPoA)

External links

• RFC 2516 - A Method for Transmitting PPP Over Ethernet (PPPoE)
• RFC 3817 - Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE)
• RFC 4638 - Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)
• US Patent 6891825 Method and system of providing multi-user access to a packet switched network