When you build a broadband edge you pick one of two access models for how subscribers reach the BNG: PPPoE or IPoE. The choice shapes how you identify a line, authenticate it, and what MTU your subscribers get. Netavo BNG terminates both, often on the same box. The choice depends on your access network.
PPPoE: an explicit session
PPPoE (PPP over Ethernet) wraps the venerable PPP protocol in Ethernet frames. A session is set up in two stages: a discovery handshake (PADI / PADO / PADR / PADS) finds the access concentrator, then PPP runs LCP, an authentication phase (PAP, CHAP or MS-CHAPv2) and IPCP/IPv6CP to bring up addressing. The result is an explicit, stateful session with a clear beginning and end.
Every session authenticates with a username and secret, so the BNG knows exactly who connected without trusting anything the access network inserted. LCP keepalives detect a dead line. And because PPPoE is carried in Ethernet, it works across access networks you do not control. That is why wholesale and L2TP/LNS designs are almost always PPPoE: the subscriber's PPP session rides from a third-party access provider's LAC to your LNS.
The costs are real but modest. PPPoE adds 8 bytes of header, so the subscriber MTU is 1492 rather than 1500, and anything that assumes a full 1500-byte path needs MSS clamping. Session setup has a per-connect cost. And PPPoE traffic is invisible to most NIC RSS hardware, so a naive software BNG pins it to one CPU core. There are solutions to this (see the companion note on PPPoE and NIC RSS).
IPoE: IP straight onto the wire
IPoE (IP over Ethernet) drops the session protocol. The subscriber's device does DHCP (and DHCPv6 / router advertisements for IPv6), and the BNG identifies the line not from a PPP login but from where the request arrived: the VLAN, and the DHCP Option 82 circuit-id / remote-id that the access node inserts. RADIUS then authorises the line keyed on that identity.
IPoE gives you the full 1500-byte MTU, a simpler CPE (no PPP client, no credentials to provision on the device), and a DHCP-native model that fits modern owned FTTP well. The trade is trust: you are identifying the subscriber from metadata the access network added, so your line identification is only as trustworthy as the access node's Option 82 insertion and your VLAN hygiene. On a network you own end to end that is fine. On one you do not, it is a risk.
Side by side
| PPPoE | IPoE | |
|---|---|---|
| Subscriber identity | PPP username/secret (explicit) | VLAN + DHCP Option 82 line ID |
| Authentication | PAP / CHAP / MS-CHAPv2 per session | RADIUS keyed on line identity |
| Subscriber MTU | 1492 (8-byte overhead, MSS clamp) | 1500 |
| Session lifecycle | Explicit (discovery, LCP, keepalives) | DHCP lease lifecycle |
| Best fit | Wholesale, L2TP/LNS, access you don't control | Owned FTTP, simpler CPE, full MTU |
| CPE requirement | PPP client + credentials | DHCP client only |
How Netavo handles both
The access model is a per-interface declaration, and a port can carry both while you migrate:
"dataPlane": {
"subscriberInterfaces": [
{ "ifname": "eno1", "pci": "0000:04:00.0", "rxQueues": 8,
"accessProtocols": ["pppoe", "ipoe"], "spray": "auto" }
]
},
"pppoe": { "enabled": true, "acName": "bng1" },
"ipoe": { "enabled": true }
Either way the session model is the same: strictly one session per access circuit, and dual-stack (IPv4 plus IPv6 WAN and a delegated prefix) is a single session, not two. RADIUS does the authentication and authorisation in both cases, so your AAA and billing do not change when a line is PPPoE or IPoE. For IPoE, how the line identity is carried to RADIUS is configurable: the Option 82 encoding can be presented as BBF VSAs, a NAS-Port-Id, or a calling-station suffix, to match what your RADIUS already expects.
Choosing
- Use PPPoE when you need explicit per-session authentication, when you are a wholesale LNS terminating other operators' subscribers over L2TP, or when you do not fully control the access layer and cannot trust injected line identity.
- Use IPoE when you own the access network end to end, want the full 1500-byte MTU and the simplest possible CPE, and your access nodes insert trustworthy Option 82.
- Run both if your estate is mixed: legacy or wholesale on PPPoE, owned modern FTTP on IPoE. That is common, and a single BNG handles it.
IPoE security rests on the access network. If a subscriber can spoof another's VLAN or Option 82, your line identification is compromised in a way PPPoE's per-session auth is not. Get your access-layer anti-spoofing right before you lean on IPoE at scale.
Try both against your own access network
The free evaluation build terminates PPPoE and IPoE with every feature enabled, licensed for up to 50 concurrent subscribers. Bring a line up each way against your real access nodes and RADIUS before you commit a design. Start at netavobng.com/evaluation; the access configuration reference is in the manual.