Rebuilding the Access Edge: Why We Replaced PPPoE with a Custom DHCP Server | by Mustafa Naseer | Jun, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

Rebuilding the Access Edge: Why We Replaced PPPoE with a Custom DHCP Server

Mustafa Naseer

15 min read·<br>2 hours ago

Listen

Share

Press enter or click to view image in full size

Most ISPs keep subscriber identity in a session pinned to a six-figure box. It doesn’t have to live there — and moving it into a database and a DHCP lease reshapes everything downstream, down to a small protocol I had to write to make it work.<br>Mustafa Naseer · Software Engineer · Systems & Networking<br>1. The decisions we inherit<br>Every system that lasts long enough eventually becomes harder to understand than the problem it was built to solve. This is not a failure of the system; it is a property of time. Each decision a system makes about where to keep its state — which facts live in which place, which transitions belong to which layer — becomes load-bearing once enough other things rely on it. The decisions that were once provisional, made under deadlines and with the information available at the time, harden into the assumptions everyone after builds on top of. The system stops being a thing engineers designed and starts being a thing they inherit.<br>The history of broadband access is largely the history of one such decision: the decision to make the subscriber’s identity a session. Somewhere in the move from dial-up to always-on connections, the industry settled on Point-to-Point Protocol over Ethernet — PPPoE — as the way a customer’s router would announce itself to the network. The choice made sense in its time. Dial-up had taught everyone to think in sessions; the equipment that terminated them was the natural place to also do authentication, accounting, and traffic shaping; and the operational model that grew up around it — username, password, RADIUS, a concentrator at the edge of the core — was familiar enough that operators could staff it from the talent pool they already had. It worked. It still works. A large fraction of the world’s broadband traffic passes through PPPoE sessions today, and will tomorrow.<br>But every choice of where to put state is also, silently, a choice of what becomes expensive to change. The session, once instantiated, is a stateful object pinned inside a specialized device at the heart of the access network. Suspending a subscriber means tearing down a session; expiring them means kicking them; changing their package means coordinating a change against a live tunnel. Each of these is a transient operation against a live object, and at small scale none of them are remarkable. At the scale of a regional ISP serving tens of thousands of homes, they accrete into a quiet operational tax: every lifecycle change is a small risk, every box upgrade is a coordination problem, and every conversation about capacity ends with a vendor.<br>URUFI began as an attempt to take that tax seriously enough to ask whether the underlying decision could be revisited. Not the operational habits — those are downstream — but the original choice itself. Does subscriber identity have to live in a session? What happens if it lives somewhere else?<br>This essay is a record of what happened when I followed that question honestly. It is not an argument that PPPoE was a mistake. It is closer to an argument that the world it was designed for is no longer the world we operate in, and that some of the constraints that justified its shape have softened enough that a different shape is now possible. The harder, more interesting work is in the second-order consequences — what a different shape demands of the rest of the system, and what new problems it creates in exchange for the ones it dissolves.<br>2. The session was never really the subscriber<br>The first thing to notice, if you sit with the question long enough, is that the session is never really what the operator cares about. The operator cares about whether a particular customer has paid for service this month, what package they purchased, whether their device should be allowed onto the internet or held in a captive portal, and where in the network they are. The session is just the bookkeeping mechanism that has historically carried those facts. None of those facts are inherently transport-shaped; they are inherently data-shaped. The subscriber’s package is a row. Their device is a MAC address. Their access is a firewall rule. The session is the wrapper, not the thing.<br>Once you see that, the question becomes whether the wrapper is doing any work the data could not do directly. And the answer, in a modern network, turns out to be: less than it used to. The original justifications for binding identity to the transport — the limitations of access hardware, the difficulty of querying authentication state in real time, the cost of holding lookup tables in memory — are mostly artifacts of...