← All Posts 📖 The Human DeveloperEarly access → what makes developers irreplaceable in the age of AI

Somebody Filed a Draft for IPv8

IPv6 Isn't Finished Yet, and the Next One Already Wants to Skip It

Reading time: ~25 minutes

Early April a friend sent me a link to an article about an IETF draft for IPv8. I read the headline, closed the tab, and went back to what I was doing. Of course there's a draft for IPv8. It's April. There was an April Fools IPv9 in 1994. There's a tradition.

A couple of weeks later the link surfaced again and I actually opened the draft. The filename is draft-thain-ipv8-00. The publication date at the top is 14 April 2026. The author is J. Thain, One Limited. It's on the standards track. It's not a joke.

It's also not going anywhere. One author, no working group, no implementations, nine companion drafts referenced but not filed. The IETF gets proposals like this constantly — somebody has an idea, publishes an Internet-Draft, and 99 out of 100 quietly expire after six months. Nothing in the process stops you from filing. An Internet-Draft is an idea on the record, not a commitment to ship.

But this one is interesting. Not because I think it will win — I don't — but because the diagnosis in the draft is sharper than anything I've seen written about IPv6 in a decade. The first sentence about IPv6 in the draft is:

After 25 years of deployment effort IPv6 carries a minority of global internet traffic.

That's the same observation I made in my IPv6 post. The difference is that I concluded IPv6 will eventually win because the economics will force it. The draft concludes that IPv6 already lost, and what's needed is a protocol that does what IPv6 couldn't: ship without dual-stack, and ship with the management plane built in.

That's a radical claim. Let me walk through what the draft actually proposes, what's clever about it, what's unbelievable about it, and why I think the idea matters even if this specific draft dies.

One more thing before the walkthrough. In the IPv6 post I noted that IPv5 wasn't a scandal — it was the Internet Stream Protocol (ST) and the number was just taken. IPv8 has its own version-number graveyard, and it's worth five seconds. Version 7 was originally assigned to TP/IX (RFC 1475, 1993) and later also claimed by CATNIP (RFC 1707). Version 8 was assigned to PIP — Paul Francis's "P Internet Protocol" — one of the early-1990s IPng candidates. Version 9 went to yet another proposal (TUBA), and also to the April Fools RFC 1606. All of them lost to what became IPv6, and all of them were officially moved to "Reserved (Historic)" in the IANA IP Version Numbers registry. So when Thain's draft claims the number 8, it's claiming a slot that IANA formally retired. Nothing in the process stops that — the registry is a registry, not a lock — but it's worth knowing that the number has a previous occupant who also didn't ship. IPv8 is not a green-field name. It's a headstone being stood up again.

The address, decoded

IPv6 is 128 bits. IPv8 is 64 bits. That's the first surprise — IPv8 proposes a smaller address than IPv6, not a larger one.

The 64 bits are split in half. The top 32 bits are an ASN — Autonomous System Number, the identifier every ISP, cloud provider, and sufficiently large enterprise already has assigned to it. ASNs are how the internet's backbone routing protocol, BGP, decides which network to hand a packet to; each AS announces which address ranges it owns, and every other AS learns a path through it. Google is ASN 15169, Cloudflare is 13335, AT&T is 7018. ASN 1 was assigned to BBN — Bolt, Beranek and Newman, the company that built the first IMPs for the ARPANET and is, in a real sense, the ancestor of the whole thing; after a chain of acquisitions (GTE Internetworking, Genuity, Level 3, CenturyLink, Lumen) it's still in active use on the global routing table today. The first ASN ever assigned has never been retired. There are roughly 175,000 of them in total, tracked by the same regional registries (ARIN, RIPE, APNIC, and friends) that hand out IP addresses. The bottom 32 bits are a host address inside that ASN. Written out, an IPv8 address looks like this:

<ASN>.<n>.<n>.<n>.<n>

So if you own ASN 15169 (Google's), your addresses are 15169.n.n.n.n where the n.n.n.n part is effectively an IPv4-shaped 32-bit number inside your ASN.

The math works out to roughly 4.3 billion addresses per ASN, and with about 175,000 ASNs currently allocated globally that gives you a global address space of 2^64 — 18 quintillion addresses. Less than IPv6's 340 undecillion but still hilariously large compared to IPv4's four billion.

The 64-bit choice is bolder than it looks. If Thain actually wants IPv8 to win the version-number game — and filing a draft is, at minimum, a signal you'd like that — then picking a shorter address than the incumbent successor is the single most attackable decision in the whole proposal. Every networking novice who reads the first page is going to say the same thing: wait, 64 bits? We just finished telling everyone to go to 128. How is going backwards the future? Great Scott, Thain — where we're going, we don't need 128 bits. That's the objection the draft will get in every room it walks into.

The draft does defend 64 bits — the whole ASN-as-routing-prefix argument is a structural defence of the split — but it doesn't engage with sufficiency as a separate question. "Why not 96, or 128, or 256, so we never have this conversation again?" isn't rebutted; it isn't even raised. Sixty-four bits is mathematically plenty (18 quintillion is a number that beats every proposed unit of addressable thing on the planet), but mathematical plenty is what Vint Cerf said about 32 bits in 1981 too. Defensibility and sufficiency are different arguments, and the draft is relying on sufficiency alone. That's a real choice, and it's the kind of choice that gets made when you care more about the routing-table bound than about winning the political fight in the working group. Thain may be right about the technical answer. He's made the political answer harder than it had to be.

And credit where it's due: the draft doesn't call this out, but a designer willing to pick the smaller number because the smaller number composes better with the rest of the system is a designer I trust more than one who reaches for 256 bits to shut down arguments. The elegant systems — the ones that age well — are the ones built on trade-offs someone took seriously instead of papering over. 64 here is a trade-off. 128 would have been a concession. Thain picked the one that's harder to sell and easier to live with. That's a small thing, but it's the kind of small thing that marks out the people who actually design protocols from the people who just specify them.

The point of the split isn't just aesthetics. It's a routing argument. The global BGP routing table is past a million prefix entries and keeps growing, because operators announce deaggregated subnets for traffic engineering. There's no architectural bound on it — the table will grow until something breaks.

IPv8 bounds it by construction. The top-level routing table is the ASN. You announce one prefix per ASN, period. Everything below that is intra-AS routing, which is your problem, not the global DFZ's problem. The draft's claim is that the global BGP8 table is structurally bounded at one entry per ASN — approximately 175,000 today. New ASNs are allocated over time, so the number grows, but it grows slowly and linearly, not exponentially, and it's bounded architecturally rather than by policy.

That's the part I find most interesting. It's not the address space. It's that the address layout is also the routing hierarchy, and the hierarchy is the existing ASN system. You don't have to invent a new allocation authority or migrate operators to new identities. The routing tree is ARIN/RIPE/APNIC's existing work.

IPv4 as a subspace

Here's the trick that makes the draft worth reading even if nothing else in it ships.

IPv4 is a proper subset of IPv8. An IPv8 address with the routing prefix field set to zero is an IPv4 address.

Think about what that sentence is claiming. An IPv8 address where the ASN field is all zeros — 0.n.n.n.n — is literally an IPv4 address. Not an encapsulation, not a tunnel, not a translation. The lower 32 bits are bit-for-bit an IPv4 address. The same routers, the same NATs, the same home gateway your ISP shipped — they see an IPv8 packet with ASN=0 as a packet carrying their IPv4 world, unchanged.

This is a stab at solving IPv6's single biggest problem, which is that IPv6 is a separate stack. To run IPv6 you run two stacks. Every router, every firewall, every monitoring tool, every IPAM system needs IPv6 code paths in addition to IPv4 code paths. The cost of that duplication is what killed 25 years of IPv6 adoption in enterprise networks. If you already have an IPv4 network that works, the marginal benefit of adding an IPv6 stack is zero, and the marginal cost is everything you already own, reimplemented.

IPv8 sidesteps that by saying: your IPv4 network is an IPv8 network. It's the part of IPv8 where the ASN routing prefix is zero. You don't have to add a second stack. You light up ASNs gradually as they're useful, and every device that doesn't understand IPv8 keeps seeing the IPv4 it already knows.

Whether this actually works in practice is a different question. The draft is light on what happens at the border between ASN=0 packets and packets with a non-zero ASN, and the reality of making two address interpretations coexist on the same wire is harder than the prose suggests. But as a protocol-design idea, "the legacy is a subspace of the new thing" is more honest than "run both stacks for 25 years."

The missing piece: who gets an ASN?

The whole design rests on one assumption I glossed over above: that everyone who wants a globally routable identity has an ASN. Go back and re-read the architecture. Your address is your ASN plus a host number. If you don't have an ASN, you don't have an IPv8 address — you have someone else's IPv8 address with a number after it, which is the thing IPv6 was supposed to end.

So who gets an ASN? Today, under RFC 1930 and current RIR policy, you need to be multi-homed to at least two other ASes, demonstrate a unique external routing policy, pay ARIN's application fee and an annual charge, and prove you're an organisation rather than an individual. There are about 175,000 ASNs allocated globally. That's 175,000 organisations, not 175,000 people and definitely not 175,000 devices. Your laptop doesn't have an ASN. Your home network doesn't have an ASN. Your small business probably doesn't have an ASN. You live inside your ISP's ASN, sharing their address space, and that arrangement is exactly the thing IPv6 tried to fix by giving every device a globally unique address.

The draft is silent on this. I mean silent. I went looking in the main draft, in the two later revisions (-01 and -02, both filed after the original), and in the nine companion drafts the main document references for "full specifications" of adjacent mechanisms. As of writing, the companion drafts I checked all 404 on the IETF datatracker — they haven't been filed yet, though that could change after this post goes out. The most promising name, draft-thain-rine-00 (Regional Inter-Network Exchange), sounds like it might be the allocation-policy document, but in the main draft RINE is only an address-range reservation (100.0.0.0/8) for AS-to-AS peering at exchange points. Not an RIR reform. Not a new allocation authority. Not anything that changes who gets an ASN.

The only times the draft mentions ASN allocation are four sentences that tell IANA which ASN ranges not to allocate — the 127.x internal-zone block, the RINE peering block, 65533/65534 for private use. That's it. The affirmative question — who gets a public ASN, under what rules, and how do we scale from 175,000 orgs to the billions of devices the draft promises end-to-end addressability for — isn't raised, let alone answered.

This matters because it's not a peripheral oversight. The 32/32 split is the whole proposal. ASN-as-routing-prefix is what delivers the bounded routing table, the ASN=0 compatibility story, and the "every device globally routable" pitch. All of those depend on ASNs being broadly available. The draft even admits the gap in §16 (Cloud) without naming it: VPC overlap, it says, is resolved "through ASN-based disambiguation." That only works if every cloud tenant has its own ASN — which they don't today and the draft doesn't say they will — or if tenants live inside the provider's ASN and get re-multiplexed into the 127.x internal-zone prefix. The second option is NAT wearing a different hat — see what I did there. The draft's own Cloud section implies it without ever saying the word.

There are essentially three futures for IPv8's ASN story, and the draft picks none of them:

  1. Keep RFC 1930 policy. Then IPv8 is a protocol for 175,000 organisations, and everyone else continues living behind their ISP in a shared block. That's fine — but it kills the "every device directly addressable" pitch and makes the whole thing look a lot more like IPv4+BGP-with-bigger-prefixes than a generational successor.
  2. Reform RIR policy to issue ASNs per-organisation-or-individual at scale. That's a huge operational, economic, and political project — RIR funding, allocation rate, routing table growth under RPKI — and it needs its own RFC. Several of them. The draft doesn't propose any.
  3. Sub-allocate inside ASNs via a new delegation scheme. That's NAT-inside-an-ASN, possibly via the 127.x internal-zone prefix, and it re-creates the end-to-end breakage IPv6 was supposed to fix. Also not in the draft.

This is the question a working group would ask in the first ten minutes and the draft would die on it. It's the kind of hole you don't get to have when you're claiming to replace the internet's addressing layer.

The Zone Server: management in the protocol

This is the part of the draft that departs most from IETF tradition, and it's the part I have the deepest critique of. Here's the draft's own summary:

The central operational concept in IPv8 is the Zone Server — a paired active/active platform that runs every service a network segment requires.

Every service. Let me enumerate what the draft bundles into that Zone Server:

One box. Active/active paired for reliability. One configuration surface. One observability surface.

Every IETF person just sat up straight. This is not how the IETF thinks. The IETF ships layered protocols — DHCP is one RFC, DNS is another, NTP another, and the whole point is that you assemble them independently. Vendors build products that happen to implement them. Operators integrate those products against their own logging, their own auth, their own monitoring. The layering is the reason the internet can have diversity at all — take it away and you have a vendor platform, not an internet.

The draft is betting that the layering has outlived its usefulness. Its opening motivation is this:

Modern network management is characterised by fragmentation. DHCP, DNS, NTP, logging, monitoring, and authentication are separate products, separately licensed, separately configured, and separately maintained with no shared awareness of network state.

That's not wrong. Anyone who has spent time inside a corporate network knows it's true. Your DHCP server doesn't talk to your DNS server talks to your NetFlow collector talks to your SIEM talks to your IPAM — each of them a separate product from a separate vendor, each with its own data model, each slightly out of sync with the others. The fragmentation is real and the operational cost is enormous.

The question is whether the fix belongs in the protocol or in the product. The IETF's historical answer has been: in the product. Ship layered protocols, let vendors integrate. The draft's answer is: in the protocol. Specify the integration as part of the standard. If you don't, you get 30 years of partial deployment because the integration cost dominates the protocol benefit.

I have sympathy for both sides. The IETF answer is right for open ecosystems — you get AWS and Cloudflare and Kubernetes and Cisco all interoperating because nobody owns the integration. The draft's answer is right for operational reality — AWS and Cloudflare and Kubernetes and Cisco all end up building the same integrated management plane internally, re-inventing the wheel each time, because no standard specifies it.

My instinct is the draft overreaches. OAuth token caching in the IP layer is a category error. But the observation that the management plane needs to be specified somewhere, and that leaving it to vendors produced 30 years of fragmentation, is correct.

There's something else going on here, though, and it's been bothering me since I first read this section. The Zone Server is a closed system. One box, all services, one vendor, one configuration surface, one observability surface. It is the opposite of how the internet was designed. The internet is layered, orthogonal, multi-party — DHCP doesn't know about DNS, DNS doesn't know about NTP, and the fact that they don't know about each other is what lets a Cisco router and a BIND server and an ntpd daemon all show up on the same network from different companies and interoperate. That separation is the entire architecture, not an incidental feature of it. It's not a bug that these services are distinct; it's the thing that made the internet possible as a multi-organisation system instead of a single vendor's product. I've written about this in my upcoming book — one of the patterns you learn to watch for when throwing AI at an open-ended design problem is that AI reaches for the closed, unified, single-organ answer almost every time. Asked to design a management plane, an LLM will hand you one system that does everything. Asked how to let a thousand companies collaborate without any of them being in charge, it struggles. Elegance, in LLM output, looks like consolidation. Elegance, in systems that actually survive, looks like separation into orthogonal components with clean interfaces.

I'm not saying the Zone Server section was dictated by a model. I have no way to know. But the shape of it — integrated, unified, eight spokes from one hub — is the shape an LLM produces when asked to fix fragmentation. A human who has shipped protocols for a living, who has watched a working group argue about where a responsibility should live for six months, tends to design the other way. You pick one thing the protocol specifies, and you draw a line around what it doesn't. The draft draws no lines. That's the tell.

Why it will probably not ship

Let's be frank, it won't. Sorry Thain.

The draft is a single author with no working group sponsorship, no implementations, no vendor commitments, and nine companion drafts that don't exist yet. The IETF process isn't what blocks it — anyone can file a draft — but IETF consensus is what makes a draft matter. Without a working group taking it up, the draft expires in six months and nothing happens.

The technical content is also over-scoped for a version-00 draft. A single submission proposes: a new address layout, a new header format, four new routing protocols (BGP8, iBGP8, OSPF8, IS-IS8), a new cost metric (CF), a new management plane (Zone Server with eight integrated services), new hardware requirements (NIC-level rate limiting that firmware must enforce), and a new WiFi protocol (WiFi8). Each of those deserves its own working group and years of debate. Bundling them into "IPv8" and expecting the bundle to ship is the same mistake IPv6 made with IPsec-as-mandatory, at ten times the scale.

And then there's the fundamental problem that killed IPv6, which applies here unchanged: nobody is in enough pain to migrate. Your home router works. Your AWS load balancer works. Your enterprise 10.0.0.0/8 has 16 million addresses and your company has 200,000 devices. The math is not close. The pain that would force a migration doesn't exist.

The draft's answer to "why will this ship when IPv6 didn't" is essentially: because IPv8 doesn't require dual-stack, the migration cost is lower. I think that's true on paper and wrong in practice. Even if IPv8 were a zero-cost migration — which it isn't — the value proposition is still invisible to anyone who isn't running a Tier 1 ISP or a hyperscaler. The senior network engineer at Mid-Sized Bank has no reason to care about the global BGP table growing past a million entries. That's a problem for 50 people on earth.

A note on how the draft was written

I read the draft twice. The second time I read it the way I read code I suspect a junior wrote with help — looking for the seams. They're there. The sentence "After 25 years of deployment effort IPv6 carries a minority of global internet traffic" appears almost verbatim in two different sections (§1.2 and §2.1) — the kind of near-exact repetition that shows up when a model regenerates a framing in two passes and neither pass got edited against the other. The three Device Compliance Tiers in §17 (Tier 1, Tier 2, Tier 3) each get the same shape of bullet list, in the same order, with the same cadence. The seven subsections of §18 Security Considerations are each one paragraph, each threat-then-mitigation, each the same length. The phrase "Full specification in [REF]" appears six times word-for-word, as a ritual section-closer. Twenty sections, zero typos. No hedge anywhere about the proposal's own weak points — no "open questions," no "this may not scale," no acknowledgment of the kind of trade-off that working-group review surfaces in week one. A 20-section protocol draft with no hedges is not a document written by someone who has been in a working group meeting.

On the other hand, the central design idea — ASN as the routing prefix, IPv4 as the ASN=0 subspace — is a real insight, and it's consistent across every section. The invented terminology (DHCP8, OSPF8, WHOIS8, XLATE8) is used correctly throughout. The RFC citations are real and appropriate. Someone who understands networking kept their hand on the tiller.

These are the prose-level seams. But there's a second set of seams that's harder to see and, I think, more telling: the shape of the solution. I made the argument earlier — the Zone Server is a closed, unified, single-organisation answer to a problem whose existing solution is layered, orthogonal, and multi-party. It's the answer a model gives when you ask it to fix fragmentation: one box, all services, one configuration surface. A human who has spent years inside the IETF's committee culture would build the other way, because they have felt in their bones how much of the internet's robustness comes from refusing to put things in one box. The two signals point the same direction from different altitudes. The sentence-level evidence (repeated framings, ritual closers, zero hedges) is consistent with an LLM producing the prose. The architectural evidence (holistic bundle, no lines drawn around what's out of scope) is consistent with an LLM producing the design. When both the words and the shape are pulling the same way, the pull is worth taking seriously.

My read: the draft is largely LLM-written. The insight is a human's. A lot of the prose is not. And that's a new situation for the IETF — a single author with a good idea and a language model can now produce a 20-section Internet-Draft in an afternoon, and to a reviewer reading it cold, it reads like work. The question I'd want to ask J. Thain, and the only person who can answer it, is whether the core conception is theirs or the machine's. I think it's theirs. I can't prove it. Neither can the IETF. That's a problem the process hasn't caught up with yet.

On the protocol

The draft will likely expire. But the diagnosis in it — that IPv6's failure was operational, not technical — is a truly useful framing. The address space was the visible feature. The dual-stack cost was the hidden killer. Every IPv6 advocate I've ever talked to focuses on the former and hand-waves the latter. The draft puts the hand-waved part first and builds the proposal around it.

That reframing, whether or not IPv8 ever ships, is useful. It tells us what the successor protocol — whatever it turns out to be called — has to look like to actually win. It has to:

  1. Be a legacy superset, not a parallel stack. Dual-stack killed v6. Any successor that asks operators to run two of everything will die the same way.
  2. Bound the routing table by construction. Not because we're at 900k entries today, but because unbounded growth is a problem someone will eventually have to solve and solving it later is more expensive than solving it in the design.
  3. Include the management plane. Not as mandatory integrated product, but as specified integration points between the protocol and the operational services around it. Leaving the integration to vendors is leaving the adoption problem unsolved.
  4. Not require new hardware. Any proposal that needs a NIC firmware change is dead before it starts. Software first. Hardware much, much later.

I'd add a fifth: visible to end users or it won't happen. HTTP/2 won in five years because users saw faster pages. IPv6 stalled for 25 years because users saw nothing. AWS charging for IPv4 addresses was more effective than two decades of IETF advocacy because it showed up on a CFO's invoice. Whatever replaces IPv4 has to either create visible user pain on the legacy path, or create visible user benefit on the new path. Neither is required for the protocol to be technically superior. Both are required for the protocol to actually deploy.

The draft's author is one person with an idea and no working group. The idea is more useful than the draft. Read it for the diagnosis, not for the prescription.

On the authorship

I came to this draft expecting a joke and left with a more useful frame for my IPv6 post from a few months back. That post ended with "IPv6 will win eventually, because the economics will force it." I still believe that. But the more precise statement is: either IPv6 wins because the legacy path gets too expensive, or something like IPv8 wins because it offers a migration path IPv6 doesn't. Both are possible. Neither is imminent. The getaddrinfo() abstraction layer keeps working, and as long as it does, most developers will never have to care which version of IP carried their bytes.

I've been pretending this post is about a protocol draft. It is, partly. The other half — the half that's going to age — is about how the draft got written. Put Claude and me in front of a whiteboard with a case of Red Bull. Queue up INXS's Kick — you need exactly that rhythm to design infrastructure, trust me. Tell us to fix IPv4/IPv6. I'm fairly sure we'd end up with a draft that looked a lot like this one. We'd rant about dual-stack through New Sensation. We'd hit the IPv4-as-subspace insight somewhere in Devil Inside. By the time Suicide Blonde came around on the second loop, there'd be eight services hanging off a Zone Server, Claude would be generating MUST/MAY lists with great enthusiasm, and I'd be nodding along because with Michael Hutchence in the room, everything composes.

The sober-morning edit — where you draw the line around what's in scope and cut everything else — that's the part a working group does for you. Neither of us would do it. So when I say the draft reads LLM-assisted, I'm not throwing stones from high ground. I'd throw the same stones at something I'd produced the same way. The point is not about the author, it's about the generative process.

One thing I'm pretty sure I'd have caught, though: the ASN allocation hole. Not because I'm smarter than Thain (I'm not — or maybe I am, who cares) but because the first thing you do after sketching a design is imagine posting it to Hacker News, and the first comment I'd expect is "but how does anyone actually get one of these?" You either address that in the draft or you get flamed on the thread. At minimum we'd have written a placeholder — "ASN allocation policy is out of scope for this document and is addressed in a companion draft" — even without the companion draft ready. The anticipation of being flamed is a useful editorial force. Thain's draft doesn't anticipate it. That's what tells me the draft hasn't been through the fire yet — not the architectural overreach, but the absence of the flinch. Claude and his buddies won't make you flinch. A working group meeting certainly will.

Working groups exist for exactly this reason. They're the mechanism by which a good idea at midnight becomes a specification that can actually ship. Thain doesn't have one. Claude and I wouldn't either. But Claude and I would at least have pre-flinched.

This draft is going nowhere. But 25 years in, some people think the problem IPv6 was supposed to solve is still unsolved. And they're not wrong.

I'm writing a book about what makes developers irreplaceable in the age of AI. Join the early access list →

Naz Quadri thought this was an April Fools joke for two weeks, then read the draft and had to write a blog post about it. He blogs at nazquadri.com. Rabbit holes all the way down 🐇🕳️.

Further Reading