A new Internet Protocol Version 8 (IPv8) Internet-Draft published on the Internet Engineering Task Force (IETF) website has triggered active discussion in the networking and cybersecurity communities. The draft proposes a shift in addressing format and network architecture compared with IPv4 and IPv6, while early analysis suggests that substantial portions of the text were likely generated by artificial intelligence, further increasing scrutiny of its technical and security implications.
IPv8 addressing: 64‑bit IP addresses with IPv4‑style notation
The IPv8 proposal introduces a 64‑bit IP address space while preserving the familiar dotted‑decimal notation from IPv4. Instead of four octets (e.g. 1.1.1.1), IPv8 defines eight octets: 1.1.1.1.1.1.1.1, with each octet still ranging from 0 to 255.
This yields an address space of 264 addresses (about 18.4 quintillion unique identifiers), vastly larger than the 232 addresses in IPv4 (around 4.29 billion), yet still dramatically smaller than IPv6, which uses 128‑bit addresses and offers approximately 3.4×1038 possible addresses. From a pure scalability standpoint, IPv8 sits between IPv4 and IPv6.
A key design claim is backward compatibility with IPv4. The draft treats IPv4 as a subset of IPv8: if a routing prefix has a zero value, the address should be interpreted as a conventional IPv4 address. In theory, this promises easier coexistence and transition. In practice, however, experience with protocol migrations shows that “transparent” compatibility is rarely seamless and usually requires extensive changes in hardware, operating systems and applications.
Zone Server architecture and embedded OAuth2: merging network and application layers
Beyond addressing, the IPv8 draft proposes a fundamental redesign of network architecture. A wide range of functions—telemetry, authentication, name resolution, time synchronisation, access control and network address translation—are consolidated into a single platform called the Zone Server.
Embedding OAuth2 and JWT into the network layer
According to the draft, every managed network element must authenticate via OAuth2 using JWT tokens. In other words, mechanisms traditionally implemented at the application layer are moved directly into the core network layer protocol.
This approach conflicts with the classical OSI model, where IP resides at Layer 3 and protocols like OAuth operate at Layer 7. Most network devices—such as access switches, simple routers and industrial controllers—are not designed to perform complex application‑level authorisation. For cybersecurity, this raises several concerns: a significantly expanded attack surface, complex token and key management across infrastructure, and heightened dependency on centralized authentication and policy services.
Status of the IPv8 IETF Internet‑Draft and questions about its origin
Non‑standard status of an IETF Internet‑Draft
From a governance perspective, it is critical to understand that an IETF Internet‑Draft is not a standard and not even necessarily a formal standards proposal. Anyone can submit a draft, and its appearance on the IETF website does not imply endorsement or in‑depth review by any working group. Internet‑Drafts typically expire automatically after roughly six months unless they progress further in the process.
The IPv8 text explicitly notes that it does not represent an official position in the IETF standards track. Organizations therefore should treat it as an early idea, not as an emerging de‑facto standard.
AI‑generated text and unknown authorship
The IPv8 draft lists James Thain of One Limited, a company registered in Bermuda, as the author. This name is not recognized within the core IP standards community, and the organization has no widely known history in protocol design. Within a few days, three revisions of the IPv8 draft and roughly a dozen related documents—covering the Zone Server architecture, routing and other aspects—were posted.
Analysis of the text with tools such as GPTZero reportedly indicates that a large portion of the content was likely generated by AI, with an estimated 76% probability. While the IETF does not prohibit the use of generative AI, the prospect of AI‑written material in foundational internet protocols underscores the need for rigorous expert review, independent validation and careful threat modelling before any such ideas could be considered for standardization.
Compatibility challenges, security risks and version number conflicts
One of the draft’s central promises is that existing hardware would not need to change. Network engineers note that this is unrealistic: any current router, switch, NIC or firewall receiving an IP packet with Version=8 will not understand it and will almost certainly drop it. Supporting IPv8 would require firmware updates, new OS network stacks and application changes.
The document itself anticipates far‑reaching modifications: a new sockets API, new DNS record types, new ARP or neighbour‑discovery mechanisms, updated ICMP, and new variants of BGP, OSPF and IS‑IS, along with mandatory Zone Servers and OAuth2‑based port authentication. Combined, these requirements contradict claims of “transparent” IPv4 compatibility and instead imply a major infrastructure migration with significant operational and cybersecurity risks.
Another technical concern is that IP version number 8 has already been used for the experimental P Internet Protocol (PIP), now considered obsolete. Reusing the same version identifier at internet scale would create additional ambiguity for traffic analysis, troubleshooting tools and legacy implementations that still recognize the older experimental protocol.
The proposed strong dependence on centralized Zone Servers also introduces new single points of failure and attractive high‑value targets. Compromise of a Zone Server or its OAuth2/JWT infrastructure could allow an attacker to manipulate routing, disrupt whole network segments or mass‑revoke device access, with immediate impact on availability and integrity.
The debate around the IPv8 Internet‑Draft illustrates why organizations must continuously monitor IETF activity and apply multi‑layered expert review to new protocol proposals. Before adopting any emerging technology, security teams should assess additional failure points, token and key compromise scenarios and effects on existing traffic inspection, logging and incident response processes. Investing in staff training, participating in relevant IETF working groups and distinguishing between experimental Internet‑Drafts and mature RFC standards enables enterprises to avoid high‑risk experiments while strengthening the resilience of their network infrastructure.
