Short answer: PPPoE remains the practical default for ISPs already running MikroTik and FreeRADIUS with prepaid, expiry-led billing — it is easy to suspend, renew, and rate-limit through RADIUS CoA. IPoE is worth the migration effort mainly for large, greenfield FTTH rollouts where removing CPE login friction and per-session PPP overhead matters more than the extra access-network complexity. Most ISPs do not need to choose once and forever; many run both side by side during a multi-year transition.
Decision table: PPPoE vs IPoE at a glance
| Factor | PPPoE | IPoE |
|---|---|---|
| Authentication model | Username/password over a PPP session, RADIUS Access-Request per login | DHCP + VLAN/Option 82/MAC binding at the access layer, no login prompt |
| CPE requirement | Any router/ONT with a standard PPPoE client — cheap, widely available | CPE and OLT must support subscriber-aware VLAN/DHCP profiles — narrower hardware list |
| RADIUS/CoA support | Native and mature — near-universal CoA support for suspend/rate-change | Works, but CoA behavior varies by NAS/BRAS vendor — verify before relying on it |
| Session overhead on NAS | PPP encapsulation + per-session state table | No PPP overhead, lighter session table at high subscriber counts |
| Instant suspend/terminate | Easy — CoA disconnect drops the PPP session immediately | Depends on NAS — some enforce only at next DHCP lease renewal |
| Support team familiarity | High in India/MikroTik-heavy markets | Lower — needs access-network and DHCP debugging skill |
| Best fit | Prepaid/expiry-led ISPs already on RADIUS, MikroTik networks, small-mid ISPs | Large fiber/GPON rollouts prioritizing zero CPE login friction at scale |
What PPPoE gives ISPs today
PPPoE authenticates every session with a username and password carried over a PPP connection, almost always validated against RADIUS. This design has one big operational advantage: the session itself is the enforcement point. When a subscriber's plan expires, wallet balance runs out, or a fair-usage cap is hit, the billing platform sends RADIUS CoA and the PPP session is disconnected or re-rated on the spot — no waiting for a lease timer, no dependency on the access-layer vendor's DHCP snooping implementation. For prepaid, expiry-driven ISPs — the dominant model across Indian broadband — this immediacy is what keeps collections and enforcement tight.
The tradeoffs are real but well understood. PPP encapsulation adds a small amount of overhead per session, and the NAS/BRAS has to hold session state for every connected subscriber, which matters at very large subscriber counts. Customers occasionally forget or mistype PPPoE credentials, which generates support tickets that IPoE, with no visible login prompt, avoids entirely. Neither issue is severe enough to force a migration on its own — most ISPs running under roughly 20,000-30,000 concurrent sessions per NAS rarely notice the overhead in practice.
What IPoE changes for the subscriber and the network
IPoE removes the PPP login screen. The subscriber gets an IP address through DHCP, and the network identifies them using access-network identity — VLAN tag, DHCP Option 82 (which circuit/port they are physically connected to), or their device's MAC address. There is nothing for the subscriber to type, which is a genuine improvement in first-time setup experience, especially for less technical customers on modern mesh routers and ONTs that do not expose a PPPoE credential field cleanly.
The cost of that simplicity is that the network has to do more work to know who is who. Subscriber identity is now tied to a physical port or VLAN mapping instead of a credential, so your provisioning records — which port maps to which subscriber, which VLAN belongs to which service — have to be accurate and kept in sync as customers move, upgrade CPE, or get re-patched during maintenance. A stale port-to-subscriber mapping in IPoE causes silent misbilling in a way that a PPPoE credential mismatch simply cannot, because PPPoE fails loudly (the login is rejected) while IPoE can fail silently (the wrong subscriber's usage gets billed to a different account).
Billing and RADIUS impact: where the real difference is
The billing impact of this choice is bigger than the authentication difference alone. On PPPoE, a subscriber's commercial state (active, expired, suspended, FUP-throttled) maps directly onto RADIUS attributes returned at login and updated live through CoA. This is the pattern most ISP billing platforms, including NowaCRM, are built around: one subscriber record drives plan speed, session limits, and CoA-triggered rate changes, with the PPP session as the single point of enforcement.
On IPoE, the same enforcement has to happen through DHCP lease policy and NAS-side CoA, and vendor support for IPoE CoA is inconsistent — some BRAS platforms apply a new policy only on the subscriber's next DHCP lease renewal rather than instantly. Before committing billing logic to IPoE-based enforcement, confirm with your NAS/OLT vendor exactly how CoA behaves for IPoE sessions on your hardware, because the gap between "instant PPPoE-style enforcement" and "wait for next lease renewal" can turn into real revenue leakage on a prepaid network — a subscriber who should have been disconnected for non-payment stays online until their DHCP lease happens to expire.
CPE and subscriber-experience considerations
PPPoE works with almost any router or ONT sold in the last two decades — the client is a standard, well-tested feature. This keeps CPE cost and inventory simple: a support team can hand out a generic router and know PPPoE will work. IPoE needs CPE and access-layer hardware (OLT/switch) that correctly implement subscriber-aware VLAN tagging or DHCP Option 82 insertion. Not every low-cost ONT does this reliably, and mismatched firmware between CPE and OLT is a common source of IPoE rollout delays. If your ISP already has a fixed CPE fleet deployed for PPPoE, moving to IPoE is a hardware refresh project, not a configuration change.
Migrating from PPPoE to IPoE without breaking billing
ISPs that decide to move usually do it in phases rather than a single cutover, because the risk of a full-network switch is high and the operational payoff builds gradually. A practical sequence: (1) confirm CoA and DHCP Option 82 behavior with your specific NAS/OLT vendor in a lab, not just on paper; (2) pilot IPoE on one POP or one new FTTH build-out where CPE is being deployed fresh anyway, rather than retrofitting an existing PPPoE base; (3) keep the billing platform's subscriber record as the single source of truth for plan, expiry, and FUP state regardless of which protocol a subscriber connects through, so reports and support views do not fork into two systems; (4) only retire PPPoE on a segment once IPoE CoA and lease-renewal enforcement have been verified under real subscriber load, not just synthetic tests. Rushing the CPE swap phase — trying to convert an existing PPPoE base to IPoE without new hardware — is the most common cause of the support-ticket spikes ISPs report after this kind of migration.
Decision framework: which should your ISP choose
Choose PPPoE if you already run MikroTik or another RADIUS-native NAS, your billing model is prepaid/expiry-led, your support team is comfortable with RADIUS troubleshooting, and your CPE fleet is already deployed. This describes most small and mid-size Indian ISPs, and there is little operational upside to migrating away from it just for its own sake.
Choose IPoE if you are building a new FTTH network from scratch, want to minimize CPE-side support tickets at scale, and you have confirmed your OLT/BRAS vendor supports the CoA and DHCP Option 82 behavior your billing enforcement needs. This is more common in larger, greenfield fiber rollouts than in incremental broadband expansion.
Run both if you are mid-migration: keep PPPoE on your legacy base and IPoE on new builds, with a billing platform that treats both as connection types on the same subscriber lifecycle rather than as two separate systems to reconcile manually.
Frequently asked questions
Is IPoE more secure than PPPoE?
Not inherently. PPPoE authenticates every session with a username and password over PPP, which is easy to audit and revoke through RADIUS. IPoE relies on the access network itself — VLAN, DHCP Option 82, and MAC/circuit-ID binding — to identify a subscriber, so its security depends entirely on how tightly the OLT/BRAS locks down those bindings. A poorly configured IPoE network is easier to spoof than a poorly configured PPPoE one, not harder.
Can an ISP run PPPoE and IPoE on the same network?
Yes. Many fiber ISPs run PPPoE on legacy GPON/copper areas and IPoE on new FTTH rollouts during a multi-year migration. This works cleanly as long as the RADIUS and billing layer treats both as connection types on the same subscriber record, so plan changes, FUP, and suspension apply consistently regardless of which protocol a given subscriber authenticates through.
Does switching to IPoE require replacing customer CPE?
Usually, yes, for anything already deployed. Most PPPoE-era ONTs and routers do not support the DHCP Option 82, VLAN-per-subscriber, or 802.1x profiles that a clean IPoE deployment needs. Budget for a CPE swap or firmware upgrade cycle rather than a config-only migration — this is the single largest hidden cost ISPs underestimate when planning a PPPoE-to-IPoE move.
How does FUP enforcement differ between PPPoE and IPoE?
On PPPoE, a fair-usage breach is enforced by sending RADIUS CoA to the existing PPP session — the subscriber's speed profile changes without a reconnect. On IPoE, CoA support depends heavily on the NAS/BRAS vendor; some access nodes only apply a new policy on the next DHCP lease renewal, which can delay enforcement by minutes to hours. Confirm CoA-over-IPoE support with your NAS vendor before assuming parity with PPPoE.
Which protocol is cheaper to operate at scale?
IPoE has lower per-session overhead on the NAS since there is no PPP encapsulation or session-state table to maintain, which matters at tens of thousands of concurrent sessions. PPPoE is cheaper operationally in a different way: it needs less specialized CPE and fewer access-layer changes, so support and inventory costs stay lower for small and mid-size ISPs.
How long does a PPPoE-to-IPoE migration take for a mid-size ISP?
For an ISP with 5,000-20,000 subscribers, plan for 3-6 months: NAS/OLT configuration and RADIUS scheme changes first, a pilot on one POP, then a phased CPE swap by area. Rushing the CPE replacement phase is the most common cause of support-ticket spikes during this kind of migration.
NowaCRM supports both connection types as first-class citizens in one subscriber lifecycle: plan expiry, wallet balance, and FUP rules drive RADIUS authorization and CoA the same way whether a subscriber authenticates through PPPoE or IPoE, so a migration between the two does not require rebuilding your billing and support workflows from scratch.