What is PPPoE?

What PPPoE is

PPPoE — Point-to-Point Protocol over Ethernet — is a network protocol that creates individual, authenticated connections for each subscriber over a shared Ethernet network. DataRadius is ISP billing and management software that uses PPPoE sessions to automate authentication, speed enforcement, and disconnect/reconnect for every subscriber.

Think of it this way: an Ethernet network is like a shared hallway in an apartment building. Everyone uses the same hallway, and by default, there is nothing stopping one person from wandering into another's apartment. PPPoE adds a locked door and a unique key for each apartment. Each subscriber has their own username and password, their own session, and their own set of rules (speed limit, data cap, session duration) — all enforced by the router at the end of the hallway.

PPPoE was originally defined in RFC 2516, published in 1999. It was designed to bring the per-user session management of dial-up PPP connections to the emerging world of always-on Ethernet broadband. Over two decades later, it remains the dominant subscriber management protocol for ISPs worldwide — not because it is the newest technology, but because it solves a specific problem well: giving an ISP per-subscriber control on a shared network without requiring expensive hardware at every subscriber's premises.

How a PPPoE session works

A PPPoE session goes through three phases — discovery, session establishment, and termination — each handling a distinct part of the connection lifecycle.

Discovery phase

Before any data flows, the subscriber's device (the PPPoE client) needs to find the PPPoE server on the network. This happens through a four-message exchange:

1. PADI (PPPoE Active Discovery Initiation). The client broadcasts a message: "Is there a PPPoE server on this network?" Every device on the local Ethernet segment receives it.
2. PADO (PPPoE Active Discovery Offer). The PPPoE server responds: "I am here, and I can serve you." If multiple servers exist, the client receives multiple offers.
3. PADR (PPPoE Active Discovery Request). The client picks a server and sends a direct request: "I want to connect to you."
4. PADS (PPPoE Active Discovery Session-confirmation). The server assigns a unique session ID and confirms: "Your session ID is 1234. We are connected."

This entire exchange happens over Ethernet broadcast and takes milliseconds on a healthy network.

Session phase

Once discovery completes, the PPPoE session behaves like a point-to-point link. The client and server exchange PPP frames encapsulated in Ethernet frames, with the session ID identifying which subscriber's traffic is which.

Authentication happens immediately. The server challenges the client to prove its identity, typically using CHAP (Challenge-Handshake Authentication Protocol). The client sends its username and a hashed password. The server verifies the credentials — either locally or by forwarding them to a RADIUS server — and either accepts or rejects the connection.

On acceptance, the server assigns the subscriber:

• An IP address (from a pool or a specific static IP)
• DNS server addresses
• A speed limit (upload and download rates)
• Optional session parameters: maximum session time, interim accounting interval, data cap

From this point, the subscriber's device routes all internet traffic through the PPPoE tunnel. Every packet carries the session ID, so the server (and the router running it) knows exactly which subscriber generated each packet.

Termination

Sessions end in one of several ways:

• Subscriber disconnects. The client sends a PADT (PPPoE Active Discovery Terminate) message. The server acknowledges and tears down the session.
• Server disconnects. The server sends a PADT to the client — for example, when a billing system triggers a disconnection because the subscriber's plan expired.
• Session timeout. If a maximum session time was set during authentication, the server terminates the session when the timer expires.
• Link failure. If the physical connection drops (cable unplugged, power outage), the session ends implicitly. Most PPPoE clients detect the loss and attempt to reconnect automatically.

After termination, the subscriber's device goes back to the discovery phase and tries to establish a new session. This is why changes to a subscriber's plan — speed upgrade, account suspension, balance expiry — take effect on the next session: the client reconnects, the server queries the billing system for the current plan, and the new parameters are applied.

Why ISPs use PPPoE

ISPs use PPPoE because it gives them per-subscriber authentication, speed control, and usage tracking through a single protocol — without requiring dedicated hardware for each subscriber.

Authentication. Every subscriber proves their identity with a username and password before getting online. This prevents unauthorized access, allows the ISP to maintain a subscriber database, and ties every session to a billable account. Without authentication, anyone who plugs into the network gets access — fine for a private home network, unacceptable for a business selling connectivity.

Per-subscriber speed limits. The PPPoE server applies speed limits (rate limiting) to each session individually. Subscriber A gets 10 Mbps, Subscriber B gets 25 Mbps, Subscriber C gets 50 Mbps — all on the same physical network, all enforced by the same router. The billing system determines the speed; the router enforces it.

Usage accounting. The router tracks bytes sent and received for each session and reports them to the billing system via RADIUS accounting. This data feeds data-cap enforcement (FUP), usage-based billing, and network planning. Without per-session accounting, the ISP can see total network traffic but cannot attribute it to individual subscribers.

Session control. The billing system can disconnect a subscriber mid-session by sending a RADIUS Disconnect Message to the router. It can change a subscriber's speed mid-session by sending a Change of Authorization packet. These controls work because PPPoE sessions have identifiers — the billing system can target a specific subscriber without affecting anyone else.

Simplicity at the edge. The subscriber's device only needs to support PPPoE client mode — a feature built into virtually every router and operating system. No special hardware, no proprietary software, no provisioning at the subscriber's premises beyond entering a username and password.

How PPPoE connects to RADIUS

RADIUS (Remote Authentication Dial-In User Service) is the protocol that connects the PPPoE server on the router to the billing system — it is the bridge between "this person wants to connect" and "this person has paid."

When a PPPoE client authenticates, the router does not check credentials locally (in most ISP configurations). Instead, it constructs a RADIUS Access-Request packet containing the subscriber's username, hashed password, and the router's identifier, then sends it to the RADIUS server — which is typically the billing platform.

The RADIUS server looks up the subscriber, checks their credentials and account status, and responds:

• Access-Accept — the subscriber is valid, the plan is active. The response includes RADIUS attributes that configure the session: speed limit, IP assignment, session timeout, and accounting interval.
• Access-Reject — wrong credentials, expired plan, or suspended account. The PPPoE server drops the connection.

After the session starts, the router sends RADIUS Accounting packets at regular intervals (typically every 5 minutes) reporting data usage and session time. When the session ends, a final accounting packet records the total usage.

This architecture means the billing system is the single source of truth for subscriber access. Change a plan in the billing system, and the next time that subscriber's PPPoE session restarts, the new parameters apply. Suspend an account, and the subscriber is rejected on their next connection attempt. No logging into routers to edit individual settings.

For mid-session changes — upgrading a subscriber's speed without disconnecting them, or throttling a heavy user who hits a data cap — the billing system uses Dynamic Authorization as defined in RFC 5176. It sends a Change of Authorization (CoA) packet to the router with updated attributes, and the router applies them to the active session.

PPPoE compared to DHCP-only access

The main alternative to PPPoE for subscriber management is a DHCP-only approach, where subscribers connect and receive an IP address automatically without authentication.

Here is how they compare:

Capability	PPPoE	DHCP-only
Subscriber authentication	Built-in (username + password)	None by default
Per-subscriber speed limits	Enforced via RADIUS attributes per session	Requires MAC-based rules or separate system
Usage tracking per subscriber	RADIUS accounting per session	Requires IP-to-subscriber mapping and flow analysis
IP assignment	Per session, from pool or static	Per lease, from pool or reservation
Mid-session speed changes	CoA packet from billing system	Requires router API call or queue rule update
Subscriber device requirements	PPPoE client support	Any device with DHCP (all of them)
Setup complexity	Moderate — requires PPPoE and RADIUS configuration	Low — DHCP works with zero configuration

DHCP is simpler. A subscriber plugs in and gets an IP address. No username, no password, no configuration. This makes DHCP attractive for environments where authentication happens elsewhere — a captive portal for hotspots, or MAC-based access control for a known subscriber base.

PPPoE is more controllable. Because each subscriber has a named session tied to RADIUS, the ISP gets authentication, authorization, and accounting in a single protocol stack. Speed changes, disconnections, and usage tracking all happen through standardized RADIUS messages — no vendor-specific API calls.

Hybrid approaches exist. Some ISPs use DHCP for the initial network connection and PPPoE only for subscriber sessions. Others use DHCP with RADIUS-based MAC authentication (where the subscriber's MAC address acts as the username). Each approach trades simplicity for control.

The choice depends on your subscriber base and operational needs. Fixed-line residential ISPs with hundreds of subscribers on monthly plans almost universally use PPPoE because per-subscriber RADIUS control is essential for billing automation. Hotspot operators serving transient users often prefer DHCP with a captive portal because asking walk-in users to configure PPPoE settings is unrealistic.

When PPPoE is not the right choice

PPPoE adds protocol overhead and complexity that is not always justified — there are scenarios where simpler approaches work better.

Small private networks. If you are providing internet to a handful of units in a single building and billing is handled manually or through flat-rate leases, DHCP with MAC-based access control may be sufficient. PPPoE adds configuration burden without proportional benefit at very small scale.

Public hotspots. Walk-in users at a coffee shop or hotel cannot be expected to configure PPPoE credentials on their devices. A captive portal over DHCP — where the user connects to Wi-Fi, opens a browser, and authenticates through a web page — is the standard approach for transient access.

Networks with existing access control. If your network already handles subscriber identification at a different layer — for example, a fiber network where each subscriber's ONT is individually provisioned and MAC-authenticated — adding PPPoE on top may be redundant. Some fiber ISPs use DHCP with Option 82, where the OLT inserts the subscriber's port identifier into the DHCP request, giving the billing system the per-subscriber identification it needs without PPPoE.

High-density wireless deployments. Some access point hardware handles PPPoE poorly at high subscriber counts. If your wireless equipment does not support PPPoE passthrough reliably, a DHCP-based approach with centralized AAA may deliver better stability.

The key question: does your billing system need per-subscriber session control through RADIUS? If yes, PPPoE is the standard answer. If authentication and access control happen through other means, you may not need it.