Internet Protocol Version 8 (IPv8)
☰ Table of Contents
1. Why IPv8? The Problems With Today's Internet
The modern internet was built on IPv4 — a protocol designed in the 1970s for a network of a few hundred computers. Decades of patches, workarounds, and parallel protocols have accumulated into a fragile, inconsistent, and increasingly unmanageable infrastructure. IPv8, submitted as an IETF Internet-Draft (draft-thain-ipv8-00) in April 2026 by J. Thain of One Limited, proposes a comprehensive solution to three fundamental problems that have plagued networking for decades.
⚠ The Three Root Problems IPv8 Solves
|
Problem 1 Management Fragmentation DHCP, DNS, NTP, logging, monitoring, and authentication are all separate products with no shared awareness of network state. A device may need 12 manual configurations before becoming operational. |
Problem 2 IPv4 Address Exhaustion IANA exhausted the IPv4 address space in 2011. CGNAT patches, RFC 1918 workarounds, and ISP-level address sharing are duct tape on a crumbling wall. IPv6 was the fix — but adoption failed. |
Problem 3 Routing Table Explosion The global BGP routing table has grown past 950,000 entries with no architectural bound. Every router in the world must store and process the entire table — an unsustainable trajectory. |
The IPv6 Lesson: IPv6 addressed address exhaustion alone — and after 25 years of effort, it still carries a minority of global internet traffic. The operational cost of dual-stack transitions, combined with zero improvement in management complexity, proved commercially unacceptable. IPv8 was designed to learn from this failure.
2. IPv8 Address Format & Structure
IPv8 introduces a 64-bit address space — double the size of IPv4's 32-bit addresses. The genius of the design is its simplicity: a 64-bit address is split into two 32-bit fields, using familiar dotted-decimal notation. Every IPv4 address is already a valid IPv8 address.
Figure 1 — IPv8 64-Bit Address Architecture
IPv8 Address Format
e.g. 64512.1 · 65001.192.168.1.100
|
r.r.r.r
Routing Prefix Field (32 bits) ▶ Encodes the Autonomous System Number (ASN) of the owning organization ▶ Each ASN holder owns a full /32 routing prefix block ▶ When set to 0.0.0.0 — the address is a native IPv4 address ▶ Global routing table = one entry per ASN (structurally bounded) |
n.n.n.n
Host Address Field (32 bits) ▶ Identifies the specific device within the ASN's address space ▶ Each ASN receives 4,294,967,296 host addresses (2³²) ▶ Identical format to existing IPv4 host addressing ▶ Internal zone ranges using 127.x.x.x routing prefix for private zones |
Special Reserved Routing Prefixes
| 0.0.0.0 / r.r.r.r = 0 | Native IPv4 backward-compatible addresses — zero modification required |
| 127.0.0.0/8 | Internal Zone Prefix — never routed externally, used for private organizational zones |
| 100.0.0.0/8 | RINE Peering Prefix — Regional Inter-Network Exchange peering addresses |
| 222.0.0.0/8 | Interior Link Convention — point-to-point router links (never in global routing table) |
| 127.127.0.0 | Inter-Company Interop Prefix — cross-organization internal address translation |
IPv4 Backward Compatibility Explained: An IPv8 address where the routing prefix field (r.r.r.r) is set to 0.0.0.0 is mathematically identical to the IPv4 address in the host field (n.n.n.n). Every IPv4 device, application, and network already uses valid IPv8 addresses. No modification is needed at any layer — the "flag day" problem that killed IPv6 adoption is eliminated.
3. Zone Server — Unified Network Management
The most revolutionary concept in IPv8 is the Zone Server — a paired active/active platform that consolidates every service a network segment requires into a single, coherent management system. Instead of buying, configuring, and maintaining a dozen separate products, a Zone Server delivers everything in one unified platform.
⚒ Figure 2 — Zone Server Architecture
Zone Server
Active / Active Pair · Single Point of Management
|
DHCP8 Single lease response delivers ALL service endpoints |
DNS8 Name resolution with A8 record type & egress validation |
OAuth8 JWT token cache — sub-millisecond local auth validation |
ACL8 Access control enforcement at NIC, Zone Server & switch levels |
|
⏰ NTP8 Network time synchronisation — auto-configured via DHCP8 |
NetLog8 Unified telemetry & audit logging across all network elements |
XLATE8 IPv4-to-IPv8 translation layer — seamless cross-protocol operation |
WHOIS8 Route validation registry — every egress packet validated against active routes |
⚡ One DHCP8 Discover → One Response → Device Fully Operational
Authenticated · Logged · Time-Synced · Zone-Policy-Enforced — before the first user interaction
OAuth2 JWT Authentication: Every manageable element in an IPv8 network is authorized via OAuth2 JWT tokens validated locally by the OAuth8 cache — without round trips to external identity providers. Even in a remote location with no cloud connectivity, devices authenticate normally using locally cached public keys. Validation completes in sub-millisecond time.
4. Security Architecture: East-West & North-South
IPv8 addresses two distinct and complementary traffic security vectors that have historically been treated as separate problems requiring separate products. In IPv8, both are handled architecturally within the Zone Server framework.
️ Figure 3 — IPv8 Security Model
|
↔ East-West Security Internal traffic between devices within a network Layer 1: NIC firmware ACL8 — devices blocked at hardware from communicating with unauthorized destinations Layer 2: Zone Server gateway ACL8 — devices communicate only through designated service gateways Layer 3: Switch port OAuth2 hardware VLAN enforcement — lateral movement architecturally prevented Result: No route to any unauthorized destination exists. Lateral movement is architecturally impossible. |
↕ North-South Security Internal device traffic to the internet / external networks Validation 1: Every outbound connection MUST have a corresponding DNS8 lookup. No DNS lookup = no XLATE8 state = connection blocked. Validation 2: Destination ASN validated against WHOIS8 registry. Unregistered or bogon prefixes are dropped before the packet leaves the network. BGP8 Level: Route advertisements validated against WHOIS8 before installation. Prefix hijacking requires compromising both an RIR registry entry AND a signed WHOIS8 record. Result: The primary malware C2 channel — direct IP connections without DNS — is eliminated. |
5. IPv8 Packet Header Format
The IPv8 packet header is designed for maximum backward compatibility with IPv4. The structure is intentionally familiar — it keeps the existing IPv4 header fields and simply replaces the 32-bit source/destination addresses with 64-bit IPv8 addresses split into their two 32-bit components.
Figure 4 — IPv8 Packet Header Structure
Purple fields are new in IPv8. All other fields are identical to IPv4 — ensuring socket API compatibility with existing applications.
6. Routing Protocols: BGP8, OSPF8, IS-IS8
IPv8 evolves the existing routing protocol ecosystem rather than replacing it. Familiar protocols are updated to support 64-bit addressing and the new WHOIS8 validation mechanism, while the two-tier routing architecture dramatically reduces the global routing table size.
|
Mandatory
eBGP8 — Exterior Gateway Protocol The mandatory exterior routing protocol between Autonomous Systems. BGP8 route advertisements are validated against WHOIS8 before installation in the routing table. Routes that cannot be validated are rejected — permanently eliminating manual bogon filter maintenance and dramatically reducing prefix hijacking risk. |
Mandatory
OSPF8 — Intra-Zone Routing Used for routing within a single administrative zone. OSPF8 operates over IPv8 addresses with full support for the internal zone prefix space (127.0.0.0/8). Zones can scale to arbitrary size using familiar OSPF topology without external address coordination. |
|
Mandatory
IBGP8 — Inter-Zone Routing Routes traffic between multiple internal zones within a single ASN. Replaces complex iBGP route-reflector topologies with a cleaner zone-oriented model that aligns with the Zone Server architecture. |
Optional
IS-IS8 — Interior Gateway Protocol Optional alternative to OSPF8 for intra-zone routing. Supported for organizations with existing IS-IS deployments. Operates over the same IPv8 address structure with WHOIS8 validation support. |
️ The Two-Tier Routing Table — Solving the BGP Explosion
|
Tier 1 — Global Table One entry per ASN. Structurally bounded. Replaces 950,000+ BGP routes with ~100,000 entries (one per registered ASN). |
Tier 2 — Zone Table Internal routes within an ASN using OSPF8/IBGP8. Invisible to the global table. Scales to any size without affecting global routing. |
7. The Full IPv8 Protocol Suite
IPv8 is not a single protocol — it is a comprehensive, co-designed protocol suite of 10 companion specifications published together as a cohesive system. Each component is designed to integrate seamlessly with the others through the Zone Server platform.
Figure 5 — IPv8 Companion Specification Suite
|
IPv8 Core draft-thain-ipv8-00 Address format, packet header, compatibility |
Routing Protocols BGP8, IBGP8, OSPF8, IS-IS8, CF Two-tier routing with WHOIS8 validation |
Zone Server draft-thain-zoneserver-00 Unified management platform architecture |
RINE Regional Inter-Network Exchange ISP peering and route exchange protocol |
WHOIS8 draft-thain-whois8-00 Active route registry and BGP validation |
|
NetLog8 Unified network telemetry Audit logging & event correlation platform |
ARP8 / ICMPv8 draft-thain-support8-00 Layer 2/3 support protocols for IPv8 |
MIB / SNMPv8 draft-thain-ipv8-mib-00 Management Information Base for IPv8 |
WiFi8 draft-thain-wifi8-00 Wireless network protocol extensions for IPv8 |
️ Update8 draft-thain-update8-00 Firmware update management & NIC certification |
8. Backward Compatibility & Transition — No Flag Day
The most politically and operationally significant feature of IPv8 is its zero-disruption transition model. Unlike IPv6, which required all devices to be updated and operated in parallel dual-stack mode, IPv8 requires no changes to any existing device, application, or network to participate as a functional member of an IPv8 network.
|
✅ Single Stack Operation IPv8 operates as a single-stack protocol. No dual-stack complexity. An IPv8 network runs one protocol suite — IPv8 — and handles IPv4 devices transparently through the XLATE8 translation layer in the Zone Server. Existing IPv4-only devices join the network normally via the XLATE8 translation gateway without any awareness that they are in an IPv8 environment. |
✅ 8to4 — IPv8 Across IPv4-Only Networks The 8to4 tunneling mechanism allows IPv8 packets to traverse IPv4-only network segments transparently. IPv8 devices separated by an IPv4 network establish a tunnel that carries IPv8 traffic through the IPv4 infrastructure. This enables incremental deployment — IPv8 islands can be connected before the entire path is upgraded. |
Transition Sequence — How an Organization Adopts IPv8
|
Stage 1 Deploy Zone Servers. Existing IPv4 network continues unchanged. XLATE8 handles legacy devices. |
→ |
Stage 2 New devices deployed as native IPv8. Existing devices continue operating via XLATE8 gateway. |
→ |
Stage 3 Network naturally migrates to native IPv8 as legacy devices are retired. No forced upgrade events. |
→ |
Full IPv8 Entire network operating as native IPv8. Full management, security, and routing benefits realized. |
9. IPv4 vs IPv6 vs IPv8 — Complete Comparison
Figure 6 — Protocol Comparison Matrix
| Feature |
IPv4 RFC 791 · 1981 |
IPv6 RFC 8200 · 1998 |
IPv8 ★ IETF Draft · 2026 |
| Address Size | 32-bit | 128-bit | 64-bit (ASN + Host) |
| Address Notation | 192.168.1.1 | 2001:db8::1 | 64512.192.168.1.1 |
| Total Address Space | 4.3 billion (exhausted) | 3.4 × 10³⁸ | 1.8 × 10¹⁹ (2⁶⁴) |
| IPv4 Backward Compatible | ✓ | ✗ | ✓ 100% |
| Unified Management | ✗ | ✗ | ✓ Zone Server |
| Built-in Authentication | ✗ | ✗ | ✓ OAuth2 JWT |
| Route Validation | Manual bogon lists | ROA / RPKI | WHOIS8 (automatic) |
| Global Routing Table | 950,000+ routes (growing) | Separate table, growing | 1 per ASN (bounded) |
| Transition Model | Native | Dual-stack (costly) | XLATE8 (no flag day) |
| Current Status | Deployed (legacy) | Deployed (~50% traffic) | IETF Draft · April 2026 |
10. Current Status & Conclusion
IPv8 was submitted to the IETF as Internet-Draft draft-thain-ipv8-00 on April 14, 2026, by J. Thain of One Limited. The draft is currently on the Standards Track and is valid until October 16, 2026, when it will either be updated, extended, or allowed to expire. It has not been endorsed by the IETF and has no formal standing in the IETF standards process at this stage.
IPv8 Standardization Timeline
|
14 Apr 2026 ● PUBLISHED draft-thain-ipv8-00 submitted to IETF |
→ |
Apr–Oct 2026 ● ACTIVE Community review and IETF working group discussion |
→ |
16 Oct 2026 ● EXPIRES Draft expires unless renewed or advanced to RFC |
→ |
Future ○ TBD RFC publication, implementation, or withdrawal |
✅ Key Takeaways
| ▶ IPv8 is a complete protocol suite — not just an addressing change. It reimagines network management, security, and routing simultaneously. |
| ▶ The 64-bit address format (r.r.r.r.n.n.n.n) is elegant: ASN-based routing prefix + host address. Every IPv4 address is already valid IPv8. |
| ▶ The Zone Server consolidates DHCP8, DNS8, NTP8, OAuth8, ACL8, XLATE8, NetLog8, and WHOIS8 into a single platform — solving management fragmentation definitively. |
| ▶ The global routing table is structurally bounded at one entry per ASN — solving the BGP explosion that threatens internet scalability. |
| ▶ IPv8 is currently an early IETF draft (April 2026). It faces significant technical scrutiny — particularly around IPv6 incompatibility and the practical challenges of ASN-based addressing. It remains a concept, not a standard. |
The Internet's Next Protocol?
Whether IPv8 advances to an RFC or inspires a future redesign, it represents the most comprehensive rethinking of internet protocol architecture in decades. Follow the IETF draft for updates.
Tags
