No, this is not a joke or a typo. After years of hearing “IPv6 is the future”, an engineer has submitted a draft to the IETF to propose… IPv8. The idea? Rather than keep pushing IPv6 (which nobody has managed to fully deploy in 25 years), we start from an extended IPv4 base instead. And honestly, on paper, it looks rather promising.
IPv6, the problem#
Before we talk about IPv8, let’s remind ourselves why we’re here. IPv4 offers around 4.3 billion addresses. That seemed massive in the 80s, much less so today with billions of connected devices. IPv4 addresses have been officially exhausted since 2011 — in practice, it’s a bit more complicated than that.
IPv6 was designed to solve this problem with 128-bit addresses — a number so ridiculously large you could assign an IP to every grain of sand on the planet (just to put things in perspective). On paper, it’s perfect.
In practice? After more than 25 years, IPv6 still represents a minority of global traffic. Deployment is slow (today it’s mainly ISPs using it), complex, and requires running a dual-stack (IPv4 + IPv6 in parallel) during the transition. The result: we bodge things with NAT, CGNAT, and pretend IPv4 will hold forever.
What is IPv8?#
The draft was submitted to the IETF on 14 April 2026 by James Thain. The core idea is quite elegant: instead of breaking everything with a new incompatible address format (like IPv6), we extend IPv4 by going from 32 to 64 bits.
An IPv8 address is made up of two parts:
| Part | Size | Role |
|---|---|---|
| r.r.r.r | 32 bits | Routing prefix (ASN number) |
| n.n.n.n | 32 bits | Host address (classic IPv4 format) |
In practice, each autonomous system (ASN) would get its own pool of 4.3 billion addresses. We go from 4.3 billion addresses total to… 4.3 billion × 4.3 billion. Safe to say we’ve got headroom (still a lot of grains of sand).
IPv4 compatibility#
This is probably the smartest part of the draft. An IPv8 address with the prefix 0.0.0.0 is simply… an IPv4 address. No dual-stack, no tunnelling, no translation. IPv4 becomes a native subset of IPv8.
In theory, no device, no application, no existing network would need any modification to keep working. Adoption could happen gradually, ASN by ASN, with no imposed “D-day” — and that’s probably the most compelling point for the solution to be natively adopted.
Built-in services#
The draft doesn’t stop at addressing. IPv8 proposes a Zone Server concept that would centralise:
- DHCP8: address assignment
- DNS8: name resolution
- NTP: time synchronisation
- OAuth2 / JWT: authentication and security
- WHOIS8: route validation
- Telemetry: built-in monitoring
The idea is to have a single management point per network zone, instead of the dozen services we currently have to deploy and maintain separately.
My take (and a few caveats)#
Let’s be clear: this is a draft. Not an RFC, not a standard, not a roadmap. It’s a working document submitted for discussion. There’s a huge gap between an IETF draft and a protocol deployed in production.
That said, the approach is interesting. The starting observation is spot-on: IPv6 hasn’t managed to gain traction in 25 years, and dual-stack is an operational nightmare. On paper IPv6 solves all of IPv4’s problems, but it radically changes how things work compared to what we have now — probably a bit too much. If you wanted a comparison, it’s like being told we need to switch from regular cars to flying cars. Sure, it would solve traffic jams, but no infrastructure is adapted and most importantly, a smooth transition is impossible. Proposing a backward-compatible evolution from IPv4 rather than an incompatible revolution is pragmatic.
The caveats:
- Centralisation via the Zone Server raises questions about resilience and governance
- The draft is backed by a single author, without the weight of a consortium or major player
- The IETF receives hundreds of drafts, very few become RFCs
But hey, if it can finally get us out of NAT… and all the issues that come with it, one can dream.
