Every access network answers the same question - how does a paying subscriber get an IP address, and how do we make sure a non-paying one does not? - with one of three architectures. The choice shapes your provisioning, your billing enforcement, your support load, and which hardware you can buy for the next decade, so it is worth getting right before you have a thousand CPEs in the field.
Here is the honest comparison, from the operator's chair.
The three models in one minute
PPPoE - each subscriber's router logs in with a username and password, creating an authenticated session. The ISP's access router consults RADIUS, which returns the subscriber's plan: speed, IP, quotas. (Full explainer: What is PPPoE.)
Plain DHCP - the subscriber plugs in and gets an address, no login. Identity, if any, comes from MAC addresses or static leases. Common in small WISPs that grew out of a flat bridged network, and in apartment/hotspot deployments.
IPoE - "IP over Ethernet," DHCP's grown-up sibling. No client login, but the network identifies the subscriber: by VLAN, by switch port, by DHCP Option 82 inserted at the access device. The access router still consults RADIUS and still applies per-subscriber policy. Telco-grade fiber networks widely use this model.
What actually differs
Authentication and identity. PPPoE authenticates the subscriber - the login works from any port, any CPE, any tower. Plain DHCP authenticates nobody; MAC-based control is trivially spoofed and becomes an unmanageable list by subscriber three hundred. IPoE authenticates the line - solid where you own the access infrastructure end to end (your OLT, your VLAN per customer), weaker in messy wireless networks where subscribers roam between sectors.
Per-subscriber speed and policy. PPPoE and IPoE both deliver this through RADIUS - rate limits, address pools, static IPs, data caps arrive as session attributes (see What is a RADIUS server). With plain DHCP you are hand-carving queues per IP on the router, and every plan change is a manual touch.
Billing enforcement. The revenue question. PPPoE: suspend the account in RADIUS and the session drops or redirects to a payment page - clean, central, instant, reversible. IPoE: same lever, pulled per line. Plain DHCP: firewall rules and address-list scripts per customer, which is precisely the pile of glue that breaks quietly and hands out free internet.
Failure modes and support. PPPoE's classics: wrong credentials after a router swap and MTU/MSS issues (1492, clamp your MSS). IPoE's: misattributed VLANs/Option 82 after physical rework. Plain DHCP's failure mode is different - it fails administratively: address conflicts, unknown devices, and no authoritative answer to "was this customer online yesterday?"
CGNAT and IPv6. All three models coexist with CGNAT - the pool is just delivered per session or per line. IPv6 prefix delegation likewise rides cleanly on PPPoE and IPoE sessions; on plain DHCP it is another manually managed dimension.
Hardware freedom. PPPoE servers are commodity - MikroTik, Linux, most BRAS platforms - so mixed networks (MikroTik core, Ubiquiti or Cambium access, some fiber) stay vendor-neutral. IPoE with Option 82 needs access hardware that cooperates, which in practice couples you to your OLT/switch vendor's way of doing things.
So which one?
- Growing WISP or regional ISP, mixed vendors, per-subscriber plans: PPPoE. It is the default for a reason - identity, policy, and enforcement in one mechanism, on hardware you already own.
- Greenfield FTTH where you control every OLT and VLAN: IPoE is the modern telco answer - invisible to subscribers, no CPE credentials, same RADIUS control. Pick it if your access gear supports it properly; plenty of fiber operators still choose PPPoE for its simplicity and portability.
- Plain DHCP as your subscriber model: defensible at hotspot scale or in a building you fully manage; past a few hundred real subscribers it is technical debt with an SSID. If you are there now, the migration path to PPPoE is well trodden - and worth scheduling before the workarounds calcify.
The part the protocol does not solve
Whichever model you pick, notice what it gives you: a control lever. None of them ships the hand that pulls it. "Invoice unpaid, suspend the session," "customer upgraded, apply the new speed live," "new signup, provision credentials and an IP" - that logic lives above the protocol, and running it manually is where operator time actually goes.
ISPbox is that layer: subscribers, plans, and invoices drive PPPoE/RADIUS provisioning automatically - suspension on non-payment, live plan changes via CoA without dropping sessions, MikroTik and multi-vendor RADIUS profiles, IPv4 pools via IPAM, and IPv6 prefix delegation. The architecture debate matters; the automation on top of it is what you feel every day.
FAQ
Is PPPoE better than DHCP for an ISP? For a commercial ISP with per-subscriber plans, yes - PPPoE provides authentication, per-customer speed control, and billing enforcement through RADIUS. Plain DHCP requires manual per-customer workarounds for all three.
What is the difference between IPoE and DHCP? IPoE uses DHCP for address delivery but identifies subscribers at the network layer (VLAN, port, Option 82) and applies per-subscriber policy via RADIUS. Plain DHCP hands out addresses with no subscriber identity at all.
Is PPPoE obsolete? No. Telco FTTH deployments increasingly favor IPoE, but PPPoE remains the dominant choice for independent ISPs and WISPs because it is vendor-neutral, hardware-agnostic, and operationally proven.
Can I migrate from DHCP to PPPoE without replacing CPEs? Usually yes - most CPE routers support PPPoE client mode. Migrations typically run both models in parallel and move subscribers per sector or per plan, with credentials provisioned centrally.
