Why IPv8 Will Never Work (and the Ideas Worth Stealing)

• What Changed Since Our Read-Through
• The Verdict Out There
• My Bottom Line: the Zone Server Is Too Much Risk in One Box
• The Backward-Compatibility Claim Contradicts Itself
• The Economics Were Always Going to Be the Boss
• The Ideas Worth Stealing
• What Actually Happens Next

On July 16 we read draft-thain-ipv8 carefully and did the Zone Server math the draft didn’t — sizing the box, finding the cost thresholds, and ending on a deliberately open question: interesting bet, but can it deploy? This is the follow-up, and it closes the question. IPv8 will never work. Not “needs another revision,” not “wait for the working group” — the proposal has structural problems that revisions can’t fix, and the two biggest ones are the exact things it’s proudest of: the Zone Server and the transition story.

That’s not a dunk. A proposal this legible fails in legible ways, and the failure modes are more instructive than most protocols’ successes. So: a postmortem, written in advance, with credit where it’s due at the end.

What Changed Since Our Read-Through

Our first post reviewed draft-thain-ipv8-00, published April 14, 2026. The draft was revised twice within that same week — the current revision is -02, dated April 17. Since then: no IETF working group has adopted it, it remains an individual submission with no stream, its IANA requests (protocol version number 8, the DNS A8 record type, address reservations) sit pending, and the document expires October 19, 2026. Meanwhile it collected something most -00 drafts never get: press coverage and a real mailing-list thread. Both are worth reading, because the community said out loud the things our first post hedged.

The Verdict Out There

The Register covered the draft in May: veteran network architect James Thain, writing as an individual, positioning IPv8 explicitly as an answer to IPv6’s missing enterprise ROI. The reception it reported ran from one reader’s “a distraction and waste of time” to features being labeled “heinous” — with one notable sympathetic voice, ISP operator Silvan Gephart: “I like that there is a proposal thinking about the routing table, addressing, management, authentication and operational complexity as one bigger problem.” Hold onto that quote; it’s the part of this story that survives.

The IETF int-area thread was blunter. Daniel McLarty dismissed the draft as a “vibedrafted idea that serves no utility.” Tom Beecher called it “exceptionally naive” about why earlier protocols were designed the way they were. And Herbie Robinson supplied the epitaph for the whole category, explaining why enterprises won’t touch new network protocols: “Because they are afraid of using anything new unless they are forced to – whether it be IPv6 or IPv8.”

Three observations before we get to the technical case. First, Thain openly acknowledges drafting with chatbot assistance — he told The Register he considers it contemporary practice. Whatever you think of that as a workflow, it matters in this venue: IETF standards-making runs on earned credibility, and an individual submission that reads machine-assisted starts the trust ledger in deficit, fairly or not. Second — and this cuts the other way — almost none of the public criticism engaged with the draft’s actual numbers. People dunked on the vibe. We did the math. Both roads end at the same place, but only one of them tells you why.

Third — and this one is for all of us, not just this draft. People say harsh, vitriolic things about new technology every single day, and the harshness carries zero information about whether they’re right. “Vibedrafted” is a great line; it is not an argument. If reading an Internet-Draft makes you emotional — enraged, even — treat that as a signal to slow down, not to post. Ask what problem the author lived through that made them write thirty pages about it. Thain’s motivation isn’t mysterious, and it’s the opposite of trolling: he told The Register that existing protocols “were developed for the networking problems of the day, and things have now well and truly moved on,” and that outside the hyperscalers, IPv6 migrations rarely deliver ROI — in other words, he watched operations people decline IPv6 for decades and tried to write the version that would have been worth deploying. Understanding that doesn’t rescue the proposal; the rest of this post is about why it can’t work. But it’s the difference between a verdict and a pile-on, and only one of those is worth reading — or writing. Crucify the economics, not the author.

My Bottom Line: the Zone Server Is Too Much Risk in One Box

I’ll put my position on the record plainly, because our first post stopped short of it: the Zone Server — both the sizing and the centralization of services — makes IPv8 too risky to deploy. That alone kills it for me, before any other argument in this post.

Recall what that box is. A mandatory active/active pair per zone that is simultaneously your DHCP, DNS, NTP, telemetry collector, authentication cache, route validator, access-control engine, and IPv4 translator — and also your default gateway on every VLAN, and also your spanning-tree root. Our sizing pass found it stays boring below roughly 5–20K devices and single-digit Gbps, and crosses into serious money at three thresholds: ~10 Gbps sustained egress, ~10–50K new flows/sec with active/active state sync, and the telemetry-retention treadmill that grows linearly forever.

But the sizing was never really the point. The point is what the consolidation does to risk:

• Blast radius. As we wrote the first time: “my DHCP server is down” and “my entire network’s egress policy engine is down” are different pages in the incident runbook. The Zone Server makes them the same page. Enterprises have spent twenty years deliberately unbundling failure domains — many small zones instead of one big L2, out-of-band management, DNS changes and firewall changes on separate change boards precisely so one bad push can’t take both. The Zone Server re-bundles all of it and then puts the bundle in the data path.
• The org chart objection. DHCP, DNS, NAC, egress policy, logging, and time are owned by different teams with different vendors, different maintenance windows, and different auditors. A box that is all six at once has one change window for everything and no clean owner. A fat-fingered ACL8 push now shares an incident with your lease pool and your resolver. Anyone who has sat through a change-advisory board knows exactly how this conversation goes.
• Sharding multiplies boxes, not trust. The draft’s own escape valve — many small 127.x zones, each with its own pair — fixes the throughput math, and we credited it for that. It does nothing for the concentration problem: every zone still stakes its lease pool, name resolution, auth, and egress on the same two chassis and the state-sync channel between them.
• Nobody pilots their default gateway. There is no incremental adoption path here. The Zone Server can’t be trialed at the edge of the network the way you trial a monitoring agent — it is the middle of the network on day one, running a reference architecture from a -02 individual draft. The draft’s target buyer — the enterprise that found IPv6 too operationally expensive — is the exact buyer least able to accept that risk shape. The proposal’s cure and its market contradict each other.

The Backward-Compatibility Claim Contradicts Itself

The draft’s headline promise is total absorption: “No existing device, application, or network requires modification. The suite is 100% backward compatible.” IPv4 as a proper subset really is a clever answer to the flag-day problem — we said so, and it’s still true. But walk one step past the slogan and the promise inverts.

An unmodified IPv4 device on an IPv8 network keeps working by continuing to be an IPv4 device. It gains nothing. It doesn’t get a zone identity, DNS-gated egress, OAuth-bound switch ports, NIC-enforced rate limits, or any of the operational payoff the protocol exists to deliver. To get any IPv8 property, the device — or its NIC, or the switch in front of it — must be Tier-certified: new silicon, new firmware, new certification matrices, home routers shipping BGP stacks that will never peer. That was our “certification mountain” concern in the first post, and nothing in -02 shrinks the mountain.

So in any real network — the OT floor, the MRI machine, the point-of-sale fleet, the billing app from 2009, the switch you can’t reboot until the December window — you run a mixed estate for decades. IPv4 islands, XLATE8 translation state at every boundary, 8to4 HTTPS tunnels across non-upgraded transit. Translation plus tunneling plus two addressing models under one management plane, indefinitely — and in any shop that already deployed IPv6 somewhere, three.

That has a name. It’s dual-stack — the exact operational commitment whose “commercially unacceptable” cost is the draft’s own stated reason IPv6 failed. IPv8 doesn’t abolish the transition tax; it renames the line items and moves them into the Zone Server, the box we just declined to deploy. “Absorption, not migration” is really migration deferred into the management plane — and the management plane is precisely the thing the pitch promised would get simpler.

The Economics Were Always Going to Be the Boss

There’s an IETF document for this, and it’s older than most of the gear in your racks: RFC 5218, “What Makes for a Successful Protocol?” (and its sequel about transitions, RFC 8170). Its core finding: protocols succeed when they fill a real need and are incrementally deployable — when each early adopter captures benefit even if nobody else moves, and when the people paying for deployment are the people receiving the value. When the benefit only materializes after others deploy, early adopters eat a loss and the transition stalls.

Score IPv8 against that honestly:

RFC 5218 asks	IPv8 answers
Does an early adopter gain if nobody else deploys?	No. The routing-table bound needs the default-free zone to move; DNS-gated egress needs certified NICs on every host; the ops win needs the whole vendor matrix certified. Day-one value to adopter #1: a new failure domain.
Is deployment within one party’s control?	No. It needs silicon vendors, OS vendors, switch vendors, RIR policy, and IANA — before the first enterprise sees benefit.
Do the payers capture the value?	Partially at best. Enterprises pay for Zone Servers and re-certification; much of the promised value (bounded global table, dead C2 channels) is a commons.

IPv6 is the control group for this experiment. It had working-group consensus, three decades of runway, government mandates, RIR programs, and every vendor on board — and it still only conquered the half of the internet where one throat could be choked, while enterprise interiors stayed v4 and dual-stack settled in as a semi-permanent condition. A -02 individual draft with a hostile mailing-list thread does not have a better hand than IPv6 had. Beecher’s “exceptionally naive” and Robinson’s “afraid of anything new unless forced” are RFC 5218’s incentive analysis, restated as weariness.

The modern counterexample proves the rule: QUIC deployed at internet scale in a few years because the deployer and the beneficiary were the same parties (browser and server, often literally the same company), it needed nobody’s permission, and it hid from middleboxes to survive them. IPv8 inverts every one of those properties — multi-party permission, back-loaded benefit, and the middlebox isn’t something to evade, it’s the protocol’s beating heart.

The Ideas Worth Stealing

Here’s the part the dunks skip, and the reason we bothered writing twice about a draft that will expire in October. Several of these ideas are good — they just don’t need a new IP version, and they deserve better than to sink with this one.

1. The IPv6 postmortem. The draft’s diagnosis — dual-stack as an unpriced permanent commitment, addressing fixed while operations stayed broken, “specified independently over four decades” with no common identity or telemetry model — remains the most honest paragraph on the subject in an IETF document. Requirement writers should steal it verbatim.
2. The management-plane bundle — as software. One identity model across DHCP, DNS, NAC, egress, logging, and time is a real product gap; Gephart’s quote nails why it resonates. But nothing about that bundle requires 64-bit addresses or a new EtherType. It’s buildable today, as a control plane over boring IPv4/IPv6 — and I’d bet money the vendors mining this draft for roadmap ideas noticed. The Zone Server will ship eventually; it’ll ship as a product, not a protocol, and optional — which fixes the deployment economics and lets you keep your failure domains.
3. DNS-gated egress. “No DNS lookup, no connection” as a default posture kills hardcoded-IP C2 elegantly, and you can approximate it now with DNS-firewall and zero-trust egress patterns — no certified NICs required. Ship the posture, skip the protocol.
4. The physics floor. A routing metric that flags any path claiming to beat the speed of light over the great-circle distance is a genuinely lovely invariant — anomaly detection specified as physics. Someone should steal it for telemetry sanity-checking this quarter.
5. A structurally bounded routing table. One entry per ASN instead of 900K+ prefixes scratches a real itch. The incrementally deployable version of that conversation already exists — it’s called RPKI and ASPA, it’s grinding forward one AS at a time, and it doesn’t ask anyone to renumber the planet.

What Actually Happens Next

Nothing, and that’s the point. The draft expires in October; maybe a -03 resets the clock. No working group adopts it, because the room already told you why — not the vibes, the economics. Protocols don’t win by being right. They win by paying each adopter on day one, and IPv8 asks the most conservative buyers on the internet to concentrate their most conservative systems into one pair of boxes specified by an individual draft, in exchange for value that mostly arrives after everyone else moves too. That’s not a transition plan; it’s a coordination problem wearing one.

But read it anyway. As a protocol it’s a non-starter; as a requirements document for what network operations should feel like — one identity, one telemetry stream, explainable egress, honest metrics — it’s sharper than most product roadmaps we’ve seen this year. The right response isn’t deployment; it’s theft.

And whichever protocol your gear speaks in 2030, the 2 AM reality won’t change: something will be broken, the answer will be on a device, and somebody will be reading show output trying to reconstruct what the network actually did. That’s the problem we work on. Transit is an AI-native SSH client whose investigation-only agent reads your gear and proposes the next diagnostic command — behind a policy gate and your approval, never able to change anything. The terminal is free; the AI has a 14-day trial. No Zone Server required.

Sources: draft-thain-ipv8 datatracker (revision history, status, expiry) · our original read-through + Zone Server sizing math · The Register, May 12, 2026 · IETF int-area thread on draft-thain-ipv8-02 · RFC 5218 · RFC 8170. Quoted community remarks are as reported in the linked coverage and archive. As before: our sizing and cost claims are back-of-envelope from the draft’s stated requirements, assumptions inline in the first post — we’d still love to be argued with.