PPPoE vs IPoE: How ISPs Authenticate and Manage Subscribers

Before a subscriber gets a single bit of internet, the network has to answer three questions, in order: who are you, what may you do, and how much did you use? That is authentication, authorization and accounting — AAA — and it is the unglamorous machinery underneath every broadband bill. The two dominant ways to deliver it on a modern access network are PPPoE (PPP over Ethernet) and IPoE (IP over Ethernet, usually DHCP-based). They are not interchangeable. The one you pick shapes how you provision a customer, how cleanly you can disconnect a non-payer, how your BNG scales as you grow, and how much of your troubleshooting is a single clear session versus a forensic hunt across switches.

The temptation is to treat this as a religious war — PPPoE is “old,” IPoE is “modern” — but that framing is wrong. Both are in heavy production use at carriers of every size in 2026. The honest answer is that PPPoE gives you identity and control essentially for free at the cost of per-packet overhead and session state, while IPoE gives you efficiency and a cleaner customer experience at the cost of demanding a tightly disciplined access layer. This article walks through how each mechanism actually works, where each one breaks in production, and how to reason about the choice for your network.

How PPPoE establishes identity

PPPoE wraps every subscriber in a logical point-to-point session that runs over the shared Ethernet access network. It starts with a discovery phase, where the customer's router (the PPPoE client) finds an access concentrator — your BNG — and they agree to talk. Then PPP itself negotiates link parameters and runs authentication, almost always by relaying a username and password (typically via CHAP) to a RADIUS server. RADIUS replies with an Access-Accept that can carry far more than a yes: it can return the IP address to assign, the rate-limit profile, a session timeout, an address pool name, and vendor-specific attributes that pin the subscriber into the right policy.

The defining property is that the subscriber is an explicit, named session on the BNG. Because the session exists as a first-class object, accounting is trivial: the BNG emits RADIUS Accounting-Start when the session comes up, periodic interim updates with byte and packet counters, and an Accounting-Stop when it tears down. Disabling a customer is equally direct — a RADIUS Change-of-Authorization (CoA) or Disconnect message kills or re-rates the session in seconds, with no need to touch the customer's router or chase a DHCP lease. This is why PPPoE remains the workhorse for ISPs that bill per account and need crisp enable/disable tied to payment.

How IPoE establishes identity

IPoE removes the PPP session entirely. The subscriber's device simply does DHCP, and the network's job is to make sure that DHCP request can be trusted and attributed to the right customer. The key tool is DHCP option 82 (the relay agent information option): the access switch or OLT stamps each DHCP request with a circuit ID and remote ID that say, in effect, “this came in on port X of node Y.” The BNG or DHCP server uses that physical-location fingerprint as the subscriber's identity, because the customer never typed a password.

That shifts the trust model. With PPPoE, identity is a credential the customer presents. With IPoE, identity is something the network asserts about where the traffic entered — so it is only as trustworthy as your access-layer hygiene. Features like DHCP snooping, IP source guard, and dynamic ARP inspection stop becoming nice-to-haves and become load-bearing: without them, nothing prevents a subscriber from spoofing another's address or running a rogue DHCP server. Done right, IPoE is lighter on the wire, simpler for the customer device, and a natural fit where the access layer is yours end-to-end and strictly controlled.

Per-subscriber accounting and speed enforcement

Both models can enforce a speed profile and meter usage, but the plumbing differs. Under PPPoE, the rate limiter and the accounting counters attach to the session object the BNG already maintains, so a 50/50 Mbps plan and its byte counts live in one place keyed to the username. Under IPoE, the BNG builds an equivalent subscriber context keyed to the DHCP binding plus the option-82 location, then hangs the policer and counters off that. The capability is comparable; the difference is how fragile the binding is. A PPPoE session is self-evidently one subscriber. An IPoE subscriber context depends on the access network consistently delivering the same option-82 data — if a tech swaps a customer onto a different port without updating records, the identity can drift.

Comparison at a glance

How each fails in production

PPPoE's classic failure is the MTU and MSS trap. The PPPoE header shrinks the usable payload, so the effective MTU drops to around 1492 bytes. If MSS clamping isn't configured, you get the maddening symptom where small sites load fine but large HTTPS transfers or specific websites hang — packets that need to fragment are silently dropped because someone, somewhere, is blocking ICMP. It generates support tickets that look like “the internet is broken for one website,” and the root cause is invisible to the customer. PPPoE also concentrates load: every session is state on the BNG, so a power blip that bounces thousands of sessions triggers a re-authentication storm that hammers RADIUS all at once.

IPoE's failure modes live in the access layer. If option 82 insertion is inconsistent — a switch that doesn't stamp it, a relay that strips it, a misconfigured trust boundary — subscribers either fail to get addresses or get attributed to the wrong identity, which is worse because it can mis-bill or mis-police a customer. Because there is no password, a sloppy access layer also invites address and DHCP spoofing. And lease management becomes its own operational surface: lease times that are too long delay disconnections and reuse, while leases that are too short multiply DHCP load. With IPoE, the network's correctness is only as good as your records of which customer is on which port.

Scaling on the BNG

At 30,000+ subscribers, the choice becomes a capacity-planning question. PPPoE sessions are relatively heavy: each consumes control-plane state, and the BNG has a hard ceiling on concurrent sessions and a rate ceiling on sessions-per-second setup. The dangerous moment is not steady state but mass re-establishment after an outage, when every customer router redials at once. Your RADIUS infrastructure must be sized for that thundering herd, not the average. IPoE typically scales to more subscribers per box because a DHCP binding is lighter than a PPP session, and the recovery profile after an outage is gentler. Either way, the practical answer for large networks is to distribute subscribers across multiple BNGs and multiple RADIUS servers, and to test the recovery storm deliberately rather than discovering its limits during a real one.

How to choose

Reach for PPPoE when you bill per account and want authentication, accounting and instant enable/disable to come essentially for free; when your access layer is a mix of vendors or partly outside your control; or when you simply value the operational clarity of one session equals one subscriber. Reach for IPoE when you own and tightly instrument the access network end-to-end, when per-packet efficiency and full MTU matter, or when multicast-heavy services like IPTV make the per-session model awkward. Many carriers run both: PPPoE for residential broadband and IPoE for managed or business segments where the access path is fully controlled.

Common mistakes

• Forgetting MSS clamping on PPPoE — the single most common cause of “some sites don't load” tickets.
• Treating option 82 as optional on IPoE — without consistent insertion and snooping, identity is neither trustworthy nor billable.
• Sizing RADIUS for the average, not the storm — outages cause synchronized re-auth that can topple an undersized AAA tier.
• Letting the access layer drift out of sync with records — IPoE identity breaks silently when a customer is moved to a new port without an update.
• Decoupling provisioning from billing — manual enable/disable on routers is where revenue leaks and human error live.

The takeaway

PPPoE and IPoE are two answers to the same question — how do I know who this subscriber is and bill them correctly — and the right choice follows from how much control you have over your access layer and how you bill. PPPoE buys identity and control at the price of overhead and session state; IPoE buys efficiency at the price of access-layer discipline. Whichever you run, the operational win comes from closing the loop between authentication and billing so that a paid invoice reconnects a customer and a missed one disables them automatically, without a human touching a router. That tight coupling between RADIUS, your access concentrators and an ISP management and provisioning platform is what turns the subscriber lifecycle from a spreadsheet chore into a self-driving system.