IPv8: The IETF Draft That Could Replace Both IPv4 and IPv6

A new IETF Internet-Draft landed in April 2026 that’s turning heads: Internet Protocol Version 8 (IPv8). Not IPv5 (RTP), not IPv6 (the perpetual “next year” protocol) — IPv8. And its headline claim is extraordinary: 100% backward compatibility with IPv4, zero flag day, and it solves address exhaustion.

Let’s break down draft-thain-ipv8-00.

The Core Idea

IPv8 doesn’t replace IPv4 — it extends it. An IPv8 address with the routing prefix field set to zero is an IPv4 address. No existing device, application, or network requires modification.

The address format:

IPv8 Address: r.r.r.r : h.h.h.h
              ├──────┤   ├──────┤
              Routing     Host
              Prefix      Address
              (ASN)       (32-bit)

• Routing prefix (r.r.r.r): Encodes the Autonomous System Number (ASN)
• Host address (h.h.h.h): Full 32-bit host space per ASN

When the routing prefix is 0.0.0.0, the host address is a standard IPv4 address. Legacy devices see normal IPv4 packets.

Address Exhaustion: Solved Without NAT

Each ASN holder receives a full 32-bit host address space — 4,294,967,296 addresses per ASN. With ~100K ASNs currently allocated, that’s 400+ trillion addresses without expanding the routing table.

The global routing table is structurally bounded to one entry per ASN — compared to the 1M+ prefixes in today’s IPv4/IPv6 DFZ (Default-Free Zone).

The Management Philosophy

IPv8 isn’t just an addressing scheme — it’s a managed network suite. Every component is unified:

Zone Server: The Single Point of Control

Every IPv8 network has a Zone Server that provides:

• DHCP8: Single lease response delivers all configuration
• DNS8: Name resolution with egress validation
• OAuth2 JWT: Every manageable element authorized via tokens from local cache
• NTP8: Time synchronization
• WHOIS8: Active route registration and validation
• NetLog8: Unified telemetry

┌─────────────────────────────────────────┐
│           Zone Server                     │
│                                           │
│  ┌─────┐ ┌─────┐ ┌──────┐ ┌─────────┐  │
│  │DHCP8│ │DNS8 │ │OAuth2│ │ NetLog8 │  │
│  └─────┘ └─────┘ └──────┘ └─────────┘  │
│  ┌─────┐ ┌──────┐ ┌───────┐            │
│  │NTP8 │ │WHOIS8│ │Update8│            │
│  └─────┘ └──────┘ └───────┘            │
└─────────────────────────────────────────┘
         │
         ▼ JWT-authorized management
┌─────┐ ┌─────┐ ┌──────┐ ┌──────┐
│ Host│ │ Host│ │Router│ │Switch│
└─────┘ └─────┘ └──────┘ └──────┘

Egress Validation

Every packet leaving an IPv8 network is validated at egress:

1. DNS8 lookup confirms destination exists
2. WHOIS8 check validates an active registered route to the destination ASN
3. Invalid packets are dropped before hitting the internet

This is built-in DDoS mitigation — you can’t spoof source addresses or send traffic to unregistered destinations.

Security Model: East-West and North-South

IPv8 bakes in zero-trust principles at the network layer:

• North-South (ingress/egress): WHOIS8 route validation, DNS8 egress filtering
• East-West (lateral movement): OAuth2 JWT authorization for device-to-device communication
• Management plane: All network management operations require valid JWT tokens

No more “flat network” lateral movement. Every hop is authenticated.

Backward Compatibility

The draft emphasizes repeatedly: no flag day, no forced migration.

• IPv4 addresses are valid IPv8 addresses (routing prefix = 0)
• Legacy devices continue to work unchanged
• IPv8-aware devices can communicate with IPv4 devices transparently
• XLATE8 (translation) handles interop between IPv8-native and legacy networks
• Socket API remains compatible (extended, not replaced)

The Companion Specifications

IPv8 is not a single RFC — it’s a full suite:

What This Means for Infrastructure Engineers

If IPv8 gains traction, the implications for cloud and platform engineering are significant:

Kubernetes and Container Networking

• Pod addressing could use full 32-bit space per cluster (no more /16 CIDR planning)
• Service mesh mTLS becomes complementary to (not a replacement for) network-layer auth
• CNI plugins would need IPv8-aware IPAM

Cloud Providers

• VPC addressing becomes trivial (each VPC gets an ASN-equivalent space)
• No more RFC1918 overlap headaches in multi-cloud
• Transit gateway complexity reduced

Enterprise Networks

• NAT elimination simplifies troubleshooting dramatically
• Unified management plane replaces 5+ separate tools
• Compliance auditing via NetLog8 and JWT audit trails

Skepticism and Open Questions

This is an individual Internet-Draft (not yet adopted by any IETF working group). Key questions:

1. Is “managed” too opinionated? — IPv4/IPv6 success came from being minimal and flexible
2. Zone Server as SPOF — central management plane introduces availability concerns
3. OAuth2 at network layer — performance overhead for high-PPS routing?
4. Adoption path — even with backward compatibility, who deploys first?
5. IPv6 investment — billions spent on IPv6 transition; political will for “yet another protocol”?

The IPv6 Comparison

Related Articles

• Enable PFC on Mellanox ConnectX NICs — network infrastructure
• Linux NIC Tuning — network performance
• NVIDIA DOCA Perftest — network benchmarking
• Zero Trust Kubernetes — zero trust at infrastructure level

IPv8 is either the most elegant solution to 30 years of networking pain, or an overly ambitious “boil the ocean” proposal. Either way, it’s the most interesting IETF draft I’ve read in years. The backward compatibility claim alone makes it worth watching.