A new draft published within the IETF environment has reopened one of the oldest debates on the internet: how to definitively overcome the limitations of IPv4 without repeating the adoption challenges faced by IPv6 for over two decades. The document, Internet Protocol Version 8 (IPv8), proposes a new 64-bit addressing protocol, explicitly compatible with IPv4 and featuring a much more ambitious architecture that goes beyond addressing. It seeks to integrate management, authentication, telemetry, DNS, DHCP, NTP, route validation, and access control.
It’s important to clarify the key point: this is not an approved standard. It is an Internet-Draft, meaning a work-in-progress document that any author can submit. It does not constitute official support from the IETF unless adopted by a working group or advanced into an RFC. The IETF reminds that Internet-Drafts are valid for a maximum of six months and should be cited as “work in progress.” In this case, the initial version draft-thain-ipv8-00 was published on April 14, 2026, with a subsequent revision draft-thain-ipv8-01 appearing the next day, set to expire on October 17, 2026.
A 64-bit address based on ASN
The core idea of IPv8 is to use addresses in the form r.r.r.r.n.n.n.n. The first 32 bits would represent the routing prefix associated with the ASN—the Autonomous System Number—while the remaining 32 bits would maintain a similar semantic to a traditional IPv4 address, used to identify hosts.
Simply put, the draft proposes that each ASN holder would have 4,294,967,296 host addresses, equivalent to the entire current IPv4 space but allocated per autonomous system. The total address space would amount to 18,446,744,073,709,551,616 addresses, compared to a little over 429 million addresses in IPv4.
The stated goal is to resolve IPv4 exhaustion without requiring dual-stack migration, as with IPv6. The draft argues that IPv4 would be a subset of IPv8: an IPv8 address with the routing prefix field set to zero would be treated as a normal IPv4 address. This theoretically allows IPv4 applications to run unmodified, using a compatibility layer that manages the extra prefix transparently.
The proposal also aims to limit the growth of the global routing table. Instead of relying on millions of more specific prefixes, it suggests a structural table constrained by ASN rather than prefix length, with a minimum /16 announcement rule to prevent excessive route aggregation. This directly addresses one of BGP’s historic challenges: the increasing size of the global routing table and the difficulty in validating which routes are legitimate.
Zone Server: a single piece for DHCP, DNS, NTP, authentication, and telemetry
The most ambitious aspect of the draft isn’t just in addressing. IPv8 proposes an integrated management architecture centered around a Zone Server, an active/active platform that would group services currently managed separately: DHCP8, DNS8, NTP8, NetLog8, OAuth8 authentication cache, WHOIS8 resolution, ACL8 access control, and XLATE8 translation.
The idea is that a device entering an IPv8 network would send a single DHCP8 request and receive all required services in one response. According to the draft, the device would be authenticated, synchronized, registered, subject to zone policies, and ready to operate before the user interacts for the first time.
The document also proposes that all manageable network elements authorize through OAuth2 JWT tokens served from a local cache. This would enable, according to the proposal, identity validation without always depending on calls to external providers. In remote environments or degraded connectivity, the Zone Server could continue validating signatures with local public keys.
On paper, this vision is attractive for those troubled by fragmented network management. In practice, it’s one of its greatest challenges. IPv8 is not just a new IP protocol version; it proposes a comprehensive reordering of network operations—from addressing to authentication, access control, and telemetry. While this broad scope offers conceptual advantages, it also significantly raises implementation, validation, and adoption costs.
Security by design: east-west and north-south
The draft emphasizes reinforcing security across two planes. For east-west traffic—within the network itself—it proposes zone isolation through ACL8, ensuring devices communicate only with authorized gateways and services. The aim is to reduce lateral movement, a major concern in ransomware attacks and internal breaches.
For north-south traffic—going from the network to the internet—IPv8 recommends two mandatory security checks at the exit point: a DNS8 query associated with the connection, and destination validation against a WHOIS8 record with an active route. This approach seeks to make direct connections to malware-encoded IP addresses, common in command-and-control channels, more difficult.
Additionally, the draft suggests that BGP8 announcements be validated against WHOIS8 data before being installed into the routing table. If a route cannot be validated, it wouldn’t be accepted. In theory, this might reduce prefix hijacking, route leaks, and unauthorized announcements. Practically, it would require a robust global infrastructure for registration, signing, validation, and operation.
The awkward issue: number 8 is already reserved
One of the most delicate technical points is that the proposal requests IANA to assign IP version number 8. However, in the official IP Version Numbers registry maintained by IANA, the value 8 appears as Reserved (Historic), alongside values 5, 7, and 9. The registry states that IP version numbers are assigned through “Standards Action,” indicating that this proposal would need to pass a very rigorous process before any actual adoption.
While this detail doesn’t automatically invalidate the technical debate, it highlights the broad gap between a draft and a viable internet implementation. Changing the IP version number isn’t a minor decision—it affects operating systems, routers, firewalls, ASICs, TCP/IP stacks, monitoring tools, DNS, applications, libraries, middleboxes, and security policies across the entire ecosystem.
Furthermore, the draft emerges at a time when IPv6 can no longer be simply described as a failure. Although deployment remains uneven, Google reported that around 48% of users accessed its services via IPv6 on March 22, 2026, and APNIC measurements placed the global IPv6 capacity at approximately 43% over the 30 days preceding April 16, 2026. In other words, IPv6 has not yet fully replaced IPv4 but already carries a significant share of global traffic.
An interesting proposal, but with a highly uncertain future
IPv8 is compelling because it addresses several real frustrations: IPv4 exhaustion, dual-stack complexity, dependence on NAT and CGNAT, BGP table growth, fragmentation of network services, and weak route validation. It also serves as a conceptual exercise, prompting us to consider how we might redesign the internet differently with decades of accumulated experience.
However, its chances of adoption are, for now, highly uncertain. A proposal being technically creative is not enough; it must be implementable, compatible with existing infrastructure, acceptable to operators, manufacturers, cloud providers, operating systems, standards bodies, and businesses. It also needs to demonstrate that its benefits outweigh the costs of changing a global architecture that, despite its flaws, still functions.
The very act of consolidating so many components—DHCP8, DNS8, WHOIS8, NetLog8, Zone Server, BGP8, OAuth8, XLATE8—potentially works against it. Internet standards tend to advance more smoothly when they solve concrete problems with clear boundaries and strong operational consensus. IPv8 tries to solve many problems simultaneously, making it more striking but also more challenging to accept.
Nevertheless, the draft deserves attention as a cultural signifier. The tech community remains uncomfortable with the endless transition from IPv4 to IPv6, with dependence on CGNAT and the complexity of managing modern networks. IPv8 may never become a standard, but its emergence shows that the conversation about addressing and internet management’s future remains open.
Frequently Asked Questions
Is IPv8 an official new internet standard?
No. IPv8 currently is an Internet-Draft, a work-in-progress document. It is not approved as a standard nor has it received formal backing from the IETF, unless it proceeds through the standardization process, is adopted by a working group, and eventually becomes an RFC.
What would be the main difference between IPv8 and IPv6?
The primary difference is that IPv8 would use 64-bit addresses, with a familiar format similar to IPv4 extended, embedding the ASN in the first 32 bits. It also proposes an integrated management system with Zone Server, DHCP8, DNS8, WHOIS8, OAuth8, and telemetry.
Would IPv8 be compatible with IPv4?
The draft claims that IPv4 would be a subset of IPv8, using the 0.0.0.0 prefix in the routing part. According to the proposal, IPv4 applications could continue working via a compatibility layer, though this would need real-world validation through implementation.
Can IPv8 replace IPv6?
It’s too early to say. IPv8 is an early-stage proposal facing significant technical, operational, and standardization challenges. Plus, IPv6 already has a significant global deployment, although it still coexists widely with IPv4.