In mid-April, an Internet Draft turned up in my timelines that wants to rethink the routing foundation of the internet — with OAuth2 tokens, a central Zone Server and egress validation against WHOIS. My hot take after three readings.
Summary in 90 seconds
In April 2026, an IETF Internet Draft was submitted that wants to rethink the routing foundation of the internet: IPv8 with 64-bit addresses, a central Zone Server, OAuth2 tokens at the network layer, and egress validation against WHOIS. The draft has no IETF working-group sponsor, appears to be largely AI-generated, and contains three architectural features I consider dangerous from a DevSecOps perspective: OAuth tokens at the wrong layer, a single point of catastrophe in the Zone Server, and built-in surveillance infrastructure. Bill Buchanan sees it more kindly — but he only checked the steering wheel, didn't start the car.
When IPv8 turned up in my timelines in mid-April, I was puzzled. Was this meant to be a serious proposal? My first reflex was: somebody missed 1 April and is trying to make it work anyway. My second reflex, after I had actually read the draft: no, this is worse than a joke. This is meant.
I have been working on software development since 2002, and as DevSecOps lead I look after infrastructures, container clusters and auth architectures. When a new proposal for the plumbing layer of the internet turns up, I look closely. Especially when it sets out to bolt things into the core of the stack that have no business being there.
This is a longer piece. I’ll go through the document section by section, critically, with evidence. And I’ll also address the positive counter-piece by Bill Buchanan — a cryptography professor who sees the whole thing considerably more kindly than I do. Spoiler: I think he only looked at the steering wheel and didn’t start the car.
What is this even about?
On 14 April 2026, the Internet Draft draft-thain-ipv8-00 was submitted to the IETF, by now in revision -02. Author: J. Thain of One Limited, a company based in Bermuda. The proposal is called "Internet Protocol Version 8" and wants - nothing less - to rethink the plumbing layer of the internet.
The core points, as the draft itself formulates them:
- 64-bit address space with IPv4-style notation: 1.1.1.1.1.1.1.1
- The first 32 bits are a routing prefix bound to the Autonomous System Number (ASN). The trailing 32 bits are the host portion — effectively one IPv4 address per ASN.
- 100% backward compatibility with IPv4: an IPv8 address with routing prefix 0.0.0.0 is an IPv4 address.
- A central component called “Zone Server” that bundles DHCP, DNS, NTP, authentication, telemetry, access control and IPv4 translation in one platform.
- Every manageable element on the network authenticates via OAuth2 with JWT tokens.
- Every outbound packet is validated at egress against a DNS8 lookup and a WHOIS8-registered active route.
- Mandatory certified NIC firmware with hardware rate limits.
- Persistent TCP/443 connection from every endpoint to the Zone Server.
- New variants of BGP, OSPF, IS-IS, ARP, ICMP and a new DNS record format.
This isn’t an address-space extension. This is a complete rebuild of the stack.
First red flag: provenance
Before I even get to the technical points, there are two things everyone should soberly take note of.
First: An IETF Internet Draft is not a standard. Anyone can submit a draft. The document itself states explicitly that it has no formal status in the IETF standardisation process. If it doesn’t find working-group backing, it expires automatically after six months. As of today, this draft doesn’t have a single IETF working-group sponsor.
Second: Tools like GPTZero estimate the document is around 76% AI-generated, with individual sections at 100%. The author is unknown in the networking community — James Thain of a company in Bermuda that has left no traces in the protocol world. Within a few days, three revisions of the main document and around a dozen accompanying drafts appeared ( zoneserver-00, whois8-00, routing-protocols-00, support8-00, update8-00, wifi8-00, rine-00, netlog8-00).
On Hacker News, the thing got dismantled. The tone: “Probably someone had an Adderall fueled night with an LLM.” — “Two weeks late for April Fools’?”
This isn’t a witch hunt against AI use. The IETF doesn’t ban generative AI. But when someone proposes replacing the routing foundation of the internet with a centralised, OAuth-based construct, you expect substance, verifiable traces, a track record. All of that is missing here. This is a note about trust, not about content — but it colours every single design decision.
And now to the substance.
The serious technical problems
1. Layer violation: OAuth2/JWT at the network layer
For me, this is the biggest architectural flaw in the entire document. The draft writes: “Every manageable element in an IPv8 network is authorised via OAuth2 JWT tokens served from a local cache.”
Translated: application-layer authentication is being bolted into the network stack. This violates OSI layering at exactly the place where it matters. IP transports packets — without consulting an identity provider per packet. That’s a feature, not a bug.
Concrete problems:
Bootstrapping paradox. A device needs a JWT to communicate. But to fetch the JWT, it has to communicate. The draft solves this through local OAuth8 caches on the Zone Server — but that just shifts the trust problem. Whoever initially distributes the cache contents controls the network.
Bearer tokens in the network plane. JWTs are bearer tokens. Anyone who gets their hands on them can use them without proving anything further. By comparison: mTLS-based authentication requires key possession. Public-key schemes like OPKSSH (which we use in production) are based on short-lived certificates with proof of key possession — no bearer model. Token theft at the network layer scales in a way that we struggle to control even at the application layer.
Industry reality. Access switches, simple routers, industrial controllers, embedded controllers — these are devices not built for L7 auth. JWT validation with public-key cryptography on every switch port? In a factory floor with 800 devices? That isn’t simply “expensive” — it’s a fundamental increase in attack surface in places that today simply have no attack surface.
IPv4 and IPv6 have no built-in auth model. Auth is done at the appropriate layer: IPsec, TLS, mTLS, SASL. That’s the right place.
2. Zone Server: single point of catastrophe
The Zone Server consolidates DHCP8, DNS8, NTP8, NetLog8, OAuth8, WHOIS8 resolver, ACL8 and XLATE8 in one platform. The draft sells this as an “active/active pair with automatic failover.” That addresses availability, but not the actual problem.
The actual problem is the consolidation of trust domains.
Anyone who compromises a Zone Server controls in a single stroke:
- Identities  — via the OAuth8 cache.
- Routing  — through local WHOIS8 validation and egress control.
- Name resolution  — every lookup goes through here.
- Time synchronisation  — whoever controls NTP can defeat certificate-based validation by manipulating clocks.
- Egress filtering  — which connection is even allowed to the internet.
- Telemetry and logs  — including the forensic traces of the attack.
That’s the exact opposite of what we understand as defence in depth. A reasonably segmented network today has independent trust domains: separated DHCP, DNS resolver, RADIUS, NTP, IDS — ideally from different vendors with different update paths. A bug in one system doesn’t blow everything open.
A Zone Server is a box. An RCE in the DHCP8 implementation — and you have OAuth tokens, routing tables and logs in your hand. That’s not “active/active resilient”, that’s “eggs in one basket”.
3. WHOIS8/DNS8 egress validation: surveillance by design
The draft writes: “Every packet transiting to the internet is validated at egress against a DNS8 lookup and a WHOIS8 registered active route.”
That’s not just a technical, but also a privacy and geopolitics problem.
Surveillance. The Zone Server sees every single outbound connection with full DNS resolution in plain text and with temporal correlation. That’s a recording machine no IPv4 or IPv6 setup has by default. Whoever runs the server has a complete connection log of your network.
Censorship. Whoever controls the WHOIS8 database controls which ASNs are even reachable. In the current model, the Regional Internet Registries (RIPE, ARIN, APNIC, LACNIC, AFRINIC) are political organisations with different jurisdictions. A hard dependency of global reachability on their databases is a weapon that can be deployed against individual ASNs, individual countries, individual players.
Breaks non-DNS traffic. Direct IP connections, P2P discovery, IPsec VPN initiation without prior DNS lookup, ICMP-based tools, custom protocols — all potentially dead or having to come in through special rules. The end-to-end principle, one of the founding ideas of the internet, is quietly buried here.
IPv6 has no comparable restriction. RPKI, which we have today for BGP security, is layered and optional — an RPKI failure degrades security but routing continues to work. IPv8 makes WHOIS8 critical infrastructure in the literal sense.
4. Mandatory certified NIC firmware: hardware lock-in
A detail that’s little discussed but particularly unpleasant: every NIC must carry certified firmware, with hardware rate limits and mandatory Update8 maintenance.
That means:
- A central body (presumably coupled to the RIRs or a new IANA function) decides which hardware may participate on the network.
- Open-source implementations, custom firmware, custom hardware, hobbyist projects, old devices — potentially excluded.
- Supply-chain attacks via the Update8 system would have a reach SolarWinds only dreamt of.
IPv4 and IPv6 don’t have this hurdle. Any halfway correct implementation can join in. That’s not a historical accident, that’s the foundation of the open internet.
5. Persistent TCP/443 connection from every endpoint to the Zone Server
The draft demands a permanent connection from every endpoint to a central component. From a DevSecOps perspective, I want to note the following:
This architecture is exactly the pattern we mark as malicious in threat models. Persistent outbound TCP to a central box, from every endpoint, not switchable off — that’s a command-and-control channel by design. Whoever compromises the Zone Server has a reverse shell to every device on the network. Lateral movement isn’t necessary any more, because the movement is already built in.
What happens when the persistent connection fails? The spec is vague here. “Fail closed” would be devastating for availability. “Fail open” makes the entire auth architecture pointless. Both are bad.
6. “100% backward compatible” — the biggest lie in the document
This is the headline selling point. It doesn’t work.
Every existing IPv4 router, switch ASIC, NIC, host stack or firewall that sees a packet with Version=8 in the IP header cannot parse it and as a rule drops it. The version field is checked in hardware on the forwarding path. An 8 there breaks every existing path - unless it has been explicitly updated.
At the same time, the document itself demands:
- New socket API
- New DNS record type
- New ARP (ARP8)
- New ICMP (ICMPv8)
- New BGP/OSPF/IS-IS variants
- Mandatory certified NIC firmware
- Mandatory Zone Servers
- Mandatory OAuth2 on switch ports
- Persistent TCP/443 from every endpoint
That’s not migration light, that’s a complete hardware and software rebuild. “Backward compatible” here only applies inside a specially prepared IPv8 network that pretends to be IPv4 — not between today’s IPv4 world and tomorrow’s IPv8 world.
IPv6 honestly named dual-stack as necessary. Here that’s hidden.
7. 64 bits — a step backwards from IPv6
64-bit address space is enough today. That’s also the argument the proponents make, and I’ll come to Bill Buchanan’s variant of it shortly. But 32 bits were enough in 1981 too. The argument has a historical loop that’s noticeably under-reflected.
IPv6 with 128 bits isn’t “an address for every grain of sand”, but allows structured subnetting hierarchies, SLAAC, Privacy Extensions, EUI-64 without address scarcity. That’s architectural comfort, not megalomania.
Per ASN, IPv8 offers exactly one IPv4 table, i.e. 2³² hosts. Anyone who thinks a bit about IoT, a bit about 5G/6G, a bit about edge knows that gets tight again very quickly.
8. Version-number conflict
A detail, but telling: the version number 8 has already been assigned once — to the experimental Pip protocol from the early 1990s, today obsolete. The reuse creates tooling problems for Wireshark, IDS signatures, old stacks. Anyone exercising care checks something like that before submitting a draft. That didn’t happen here.
The counter position: Bill Buchanan
A few days after submission, a Medium article appeared by Bill Buchanan, professor of cryptography at Napier University in Edinburgh, OBE and FRSE. The man is no nobody, his track record in crypto is substantial. His article is titled “IPv6 Has Failed? Meet IPv8 — IPv4, But Better” and his core thesis is: 64 bits is the Goldilocks solution, IPv4 notation has operational value, ASN as routing prefix decentralises the internet.
His closing sentence: “It really is a brilliant way forward.”
I generally like Buchanan’s work, so I read the article twice. My impression after the second reading: he really only looked at the addressing scheme and nothing beyond.
Where Buchanan has a point
Be fair: two arguments in his article are actually substantial.
IPv4 notation has operational value. Subnetting in your head, reading routing tables, writing firewall rules, CIDR maths — generations of admins have internalised this. A notation that preserves it has a real training and migration advantage. That’s not a nostalgia argument, that’s an efficiency argument. IPv6 addresses with their colons, hex and zero compression are error-prone in practice.
IPv6 adoption is genuinely sluggish. Dual-stack complexity, NAT64/DNS64 pain, provider-side half-heartedness, faulty default configurations — the problems are real. IPv6 cheerleaders regularly underestimate them. Anyone seeing 25 years of migration and under 60% global adoption can legitimately ask whether the design is the problem.
These two points are serious and they deserve discussion.
Where he is too generous
But: both points don’t justify a “brilliant way forward” verdict on a spec whose main feature is a centralised management plane with bearer tokens, hardware lock-in and egress surveillance.
Buchanan’s article addresses only the addressing. About the actually dangerous 90% of the spec he says nothing. Not a word on the Zone Server. Not a word on OAuth2/JWT at layer 3. Not a word on DNS8/WHOIS8 egress validation. Not a word on certified NIC firmware. Not a word on the persistent TCP/443 connection. Not a word on AI provenance. Not a word on the fact that Version=8 gets dropped by existing hardware.
Three specific points where he’s factually too generous:
“IPv8 decentralises via ASNs.” That’s the wrong way round. The ASN prefix structure as such is neutral. But the spec hangs global reachability on WHOIS8 validation — every BGP8 announcement must be verified against a central registry, otherwise it doesn’t enter the routing tables. That’s not decentralisation, that’s a mandatory dependency on central RIR databases at the routing layer. BGP today works without RPKI. RPKI is optional and layered. IPv8 makes central registries critical infrastructure in the literal sense.
“IPv6 has failed.” Convenient rhetoric, but factually questionable. The Internet Society reported on 28 March 2026 that Google’s IPv6 access measurement first crossed 50%. More than half of traffic to Google runs IPv6. “Failure” looks different. It’s slow and painful, yes — but not failed adoption.
“64 bits is enough.” Enough today. Was enough in 1981 too. With IoT, 5G/6G, edge computing, perhaps in ten years ambient computing — we need address space for architecture, not just for the number of devices. IPv6’s 128 bits are forward-looking here, not excessive.
Buchanan is a cryptographer, not a network architect. His article reads like a quick, friendly reaction to a new addressing scheme, not like a substantiated assessment of the whole spec. For a three-minute piece that’s not criminal. But it is just the steering-wheel test, not the test drive.
What remains?
The IPv8 proposal is not “the next IPv6 killer”. It is an example of what happens when you try to marry real operational pain points (sluggish IPv6 adoption, growing routing tables, fragmented management) with architectural decisions from the 2026 enterprise-IT buzzword bingo: OAuth, JWT, centralisation, “Zone”.
The three points that worry me most from a security perspective:
- OAuth2/JWT at the network layer. A fundamental layer violation with a bearer-token scaling problem. JWTs belong in application-layer APIs, not in IP stacks.
- Zone Server as a monolithic trust domain. Consolidating all security functions in one box is the opposite of defence in depth. An RCE there is an RCE everywhere.
- Mandatory egress validation via DNS8/WHOIS8. Surveillance and censorship infrastructure by design, built into the routing layer.
On top of that comes the provenance problem. Who would entrust the plumbing of the internet to an apparently AI-generated spec from an unknown author in Bermuda? If the draft doesn’t find working-group support, it expires automatically after six months. That’s the likely and reasonable end.
My conclusion
This is not advice and not a recommendation — this is my hot take after reading the draft and the accompanying documents. I don’t believe this proposal in its present form will reach the internet. I wouldn’t want to deploy it in any infrastructure I know either. Continue the IPv6 migration, keep the IPv4 estate clean, RPKI at the BGP layer, DNSSEC at the DNS layer, mTLS or OPKSSH at the service layer, Vault for secrets — that works. Authentication belongs where it belongs: not in the IP header. Defence in depth works through independent trust domains, not through consolidated Zone Servers.
Anyone who wants to have an honest discussion about IPv6 pain should do so. There is room for improvement in the routing security model. There is room for improvement in management tooling. There is need for cleaner migration paths. But that happens in the IETF, in open working groups, with a verifiable track record and with real layer understanding.
Not via an anonymous draft with central surveillance architecture and hidden hardware lock-in.
That’s how I see it. Hot take, not advice.
Sources
- draft-thain-ipv8-00/01/02 on datatracker.ietf.org
- Discussion on Hacker News (item 47788857)
- GPTZero analysis via Cybernews and HackMag
- Bill Buchanan, “IPv6 Has Failed? Meet IPv8” on Medium (April 2026)
- Internet Society IPv6 adoption statistics, March 2026
Originally published at https://ole-hartwig.eu on May 2, 2026.
