PPPoE vs IPoE for ISPs: Choose the Access Model
Compare PPPoE and IPoE identity, RADIUS, accounting, CPE, support and migration workflows before choosing an ISP access model.
Compare PPPoE and IPoE identity, RADIUS, accounting, CPE, support and migration workflows before choosing an ISP access model.
Choose an identity model, not an acronym
PPPoE and IPoE can both deliver a reliable broadband service, but they establish subscriber identity differently. PPPoE creates an explicit session and commonly asks RADIUS to authenticate it. IPoE normally uses DHCP, relay information, access-port context or a combination of these signals. The right choice follows the access network, CPE fleet, support process and evidence your billing platform can reconcile.
Identity
Decide whether credentials, circuit location, device identity or a controlled combination owns access.
Accounting
Define the evidence that opens, updates and closes a billable service session.
Operations
Compare MTU, CPE setup, address assignment, troubleshooting and failure recovery.
Migration
Prove policy equivalence with a bounded cohort before changing the source of enforcement.
Understand what PPPoE makes explicit
PPPoE discovery selects an access concentrator before the PPP session begins. The session gives operators a recognizable login boundary, and RADIUS can return address, pool, rate and timeout policy. Accounting Start, Interim and Stop records then describe the session lifecycle. That explicit boundary is useful, but it does not remove the need to reconcile missing Stop packets, duplicate usernames and a NAS that becomes unreachable.
PPPoE also adds encapsulation overhead and usually needs credentials on the subscriber router. Establish the supported MTU and MSS behavior across the complete path rather than copying one value from a forum. Test dual stack, reconnect storms and CPE replacement on the RouterOS and access-device versions actually deployed.
Understand what IPoE asks the access network to prove
IPoE usually obtains addressing with DHCP and can give customers a simpler plug-and-play experience. The harder question is how the network binds a request to the correct circuit. DHCP relay information such as Circuit ID and Remote ID can carry access context, but those values are trustworthy only when inserted and protected by equipment under the ISP’s control.
Authorization and accounting behavior varies by BNG, DHCP server, RADIUS integration and vendor. Record exactly which system owns leases, subscriber policy, session visibility and disconnect behavior. A lease timestamp alone may not describe when a customer was actually online, and a MAC address alone is a fragile customer identity.
Compare the operational contract
For each access model, trace one subscriber from order through activation, address assignment, package change, suspension, restoration and closure. Compare the identifiers stored in billing, RADIUS, DHCP, the BNG or MikroTik, and support tools. An operator should be able to move from a complaint to the exact circuit and current policy without guessing.
Neither protocol decides how to bill. Billing should consume verified service and payment state, while the access system enforces an approved entitlement. Keep desired policy separate from observed session state so a failed device action remains visible instead of being mistaken for a completed suspension.
Migrate by access domain, not by database flag
Build representative tests for ordinary residential service, static addressing, IPv6 prefix delegation, business CPE, delinquency, reconnect and device replacement. Run the new decision path in shadow mode where the platform permits it, then compare addresses, rate policy and authorized customers without enforcing both systems at once.
Move one access concentrator, VLAN, OLT area or other bounded failure domain. Preserve the old policy data and a timed rollback route. During the pilot, reconcile authentication results, DHCP or PPP sessions, accounting freshness, customer tickets and unexpected fallback behavior before increasing scope.
Evidence before rollout
| Signal | Required proof |
|---|---|
| Identity chain | A subscriber maps to one service, access circuit and current enforcement record. |
| Policy result | Address, speed, timeout and IPv6 behavior match the approved package. |
| Failure state | RADIUS, DHCP, BNG and CPE failures are distinguishable and recoverable. |
| Accounting | Session or lease evidence has stable identifiers, synchronized time and a stale-state rule. |
| Support path | Staff can isolate identity, access, address and CPE faults without broad device access. |
Put the plan into operation
- Map. Document the current identity, policy, accounting and device paths.
- Lab. Test representative CPE, MTU, IPv6 and failure behavior.
- Shadow. Compare old and new entitlement decisions without double enforcement.
- Pilot. Move one bounded access domain with enhanced monitoring.
- Reconcile. Compare sessions, leases, addresses, policy and customer impact.
- Expand. Roll out only after exceptions have owners and tested recovery.
The decision standard
Choose PPPoE or IPoE only after the identity chain, policy owner, accounting evidence and failure behavior are explicit. A simpler login experience is not simpler operations if the ISP cannot prove which circuit received which service.
Research basis: IETF RFC 2516 — PPPoE; IETF RFC 2131 — DHCP; IETF RFC 3046 — DHCP Relay Agent Information Option; Broadband Forum TR-101 architecture guidance; MikroTik RouterOS PPP AAA and DHCP documentation. Validate implementation details against the releases, contracts, and local regulations governing your network.