An Individual IPv8 Draft (draft-thain-ipv8-00) Lands at the IETF, Wrapping IPv4 Inside a 64-bit Address

On April 14, 2026, draft-thain-ipv8-00 was submitted to the IETF.
The author is Jamie Thain of One Limited, based in Bermuda, and the title is exactly “Internet Protocol Version 8 (IPv8).”

It’s a regular Internet-Draft with an expiration of October 16, 2026, filed as an individual submission.
In other words, it’s not a consensus document run through an IETF working group. It’s a proposal put out by one person (or one company).

The content has a strong “let’s redo IPv6” flavor, so I read it through.
Starting from the observation that IPv6 failed to carry the majority of global traffic even after 25 years, it tries to fix not just address exhaustion, but “management plane fragmentation” and “the unbounded growth of the BGP route table” together. It’s an extremely ambitious proposal.

How IPv6 Was Actually Standardized

As a contrast, let me look back at how IPv6 went through standardization.
While IPv8’s draft is “a single person’s proposal,” IPv6 went entirely through a consensus process.

Around 1990: IPv4 address exhaustion was concretely warned about in RFC 1287 and others
1992: The IETF started discussing the umbrella concept of IPng (Internet Protocol next generation) and called for candidate proposals
1992–1993: Several candidates competed. Three representative ones:
- CATNIP (Common Architecture for the Internet): An ambitious proposal to unify TCP/IP, OSI, and IPX
- TUBA (TCP and UDP with Bigger Addresses): Use ISO CLNP’s 20-byte address in place of IPv4
- SIPP (Simple Internet Protocol Plus): An IPv4-extending direction. Started at 64 bits, eventually settled on 128
July 1994: The IPng Area Directorate issued its recommendation, adopting SIPP extended to 128-bit addresses
1995: First published as IPv6 (Internet Protocol, Version 6) in RFC 1883
1998: Revised to the modern IPv6 spec in RFC 2460 (Draft Standard)
2017: Promoted to Internet Standard (STD 86) in RFC 8200

Why “6” and Why “8” Was Open

IPv5 is skipped because the experimental streaming protocol ST / ST-II (RFC 1190, RFC 1819) had already been assigned “version 5.”
Since 5 was taken at the time of IPng candidate selection, the next open number, 6, was adopted.

7, 8, and 9 were then temporarily reserved at IANA for a while as vestiges of each candidate proposal.

TUBA → IPv7
CATNIP → IPv7 (later merged into CATNIP)
PIP (another candidate) → IPv8
TP/IX (another candidate) → IPv9

All became redundant once IPv6 was adopted, and the reservations were later cleaned up.
draft-thain-ipv8-00 is, in effect, reapplying to IANA for this “version number 8 that was left open.”

The Big Difference From IPv6: Process

IPv6 was designed by comparing three or more competing proposals inside the IETF directorate, then forming consensus around a SIPP derivative.
draft-thain-ipv8-00, on the other hand, was dropped in as a single individual draft without a WG being set up or any consensus being reached.

This difference matters later when reading how aggressive demands like BGP8 or mandatory Zone Servers are likely to land.

What IPv8 Wants to Solve

The motivations listed at the top of the draft look like this.

Motivation	Detail
Management plane fragmentation	DHCP, DNS, NTP, auth, and logging are on separate systems and don’t cooperate. IPv8 bundles them all into a single Zone Server platform
Address exhaustion and CGNAT	IPv4 allocation was exhausted in February 2011. CGNAT fills the gap but adds latency and breaks protocols. IPv6 couldn’t take off because dual-stack operational cost was too high
Unbounded growth of the BGP table	BGP4 exceeded 900k prefixes as of 2024, with no architectural upper bound. Deaggregation and missing ownership verification lead to hijacks and leaks

Where IPv6 tried to solve only “address space,” IPv8 tries to solve “addresses + management plane + routing table size + security” in a single picture. That’s the fundamental difference.

The 64-bit Address Layout

An IPv8 address is 64 bits, written like this.

r.r.r.r.n.n.n.n

r.r.r.r (32 bits) is the ASN-like routing prefix, tied to an AS number
n.n.n.n (32 bits) is the host portion, using the exact same semantics as IPv4

The total address space is 2^64 ≈ ~18.4 quintillion.
Each ASN gets 2^32 (~4.3 billion) host addresses, so CGNAT simply becomes unnecessary.

Compared to IPv6’s 128 bits with colon-separated hex, it looks entirely like “two IPv4 addresses stacked,” which massively reduces the cognitive load on operators.

IPv4 Is a True Subset

This is the most aggressive design point. Addresses with r.r.r.r = 0.0.0.0 are specified as being processed as plain IPv4.
Which means:

Zero modification to existing devices
No forced dual-stack
No migration deadline
100% backward compatibility

That’s how it’s framed.
Where IPv6 stumbled by running “a separate protocol in parallel,” IPv8 attacks from the opposite direction as “an extension that contains IPv4.”

Reserved Address Ranges

Range	Use	Routing
`127.x.x.x`	Intra-org zone prefix	Never leaked outside
`127.127.0.0`	Inter-org interconnect DMZ	Private only
`100.x.x.x`	RINE peering fabric	Not routed globally
`*.222.x.x.x`	Inter-router internal links	Convention only
`0.0.255.254`	Private BGP8 peering (ASN 65534)	Private
`ff.ff.ff.ff`	Broadcast	L2 only

The draft frames it as: give each customer VPC its own unique 127.x.x.x zone prefix to avoid RFC1918 collisions between cloud VPCs.
It’s clearly catering to cloud provider demand, too.

Packet Header Structure

The header is a straight extension of IPv4, replacing the source/destination address fields from 32 bits to 64 bits (ASN + host).

Version (4 bits) = 8
IHL, Type of Service, Total Length (same as IPv4)
Source/Destination ASN Prefix (32 bits each, new)
Source/Destination Host Address (32 bits each, new)

The header grows by 8 octets versus IPv4, a modest diff.
Compared to IPv6’s “rebuild the whole header” worldview, IPv8 is trying to keep the stack implementation cost quite low.

Bundling the Management Plane into Zone Server

Arguably more important than the addressing is the Zone Server idea: aggregating management-plane services into “a single platform running active/active.”

Service	Role
DHCP8	Returns all required service endpoints in one response
DNS8	Name resolution via the `A8` record (carries a 64-bit value, IANA submission pending)
OAuth8	JWT validation
NetLog8	Telemetry aggregation
WHOIS8	Route validation
ACL8	Access control
XLATE8	IPv4/IPv8 translation

The draft says that an endpoint on an IPv8 network receives all required service endpoints by sending a single DHCP8 Discover.
What’s striking is that the draft forcibly bundles, at the protocol layer, a modern network that’s become “a grab bag of services run by different teams on different boxes.”

Routing with BGP8 and Cost Factor

The routing protocols IPv8 requires are organized like this.

Protocol	Role	Notes
eBGP8	Inter-AS	Minimum injectable prefix is `/16`
IBGP8	Inter-zone	With Cost Factor
OSPF8	Intra-zone	OSPFv2 extension
IS-IS8	Optional internal GP	—

The BGP Table Is Capped at “One Route per ASN”

Here’s the interesting bit.
Because eBGP8 rejects injection of anything shorter than /16 at the border, the BGP8 table is structurally capped at one route per ASN, per the draft.

Today’s BGP4 is swelling past 900k. The projected BGP8 table is around 175k (roughly the number of ASN allocations).
This design goes after “the BGP convention of using deaggregation to steer traffic” itself. Opinions will definitely split.

Cost Factor: A Unified Metric Across AS Boundaries

Cost Factor (CF) is a 32-bit unified metric that combines:

RTT
Packet loss
Congestion window state
Session stability
Link capacity
Economic policy
Geographic distance (with a physical-floor check)

Where OSPF/EIGRP stop at AS boundaries, CF spans AS boundaries end-to-end.
Baking “economic policy” and “physical-distance floor” explicitly into route selection has a very current feel to it.

Security, Split Between East-West and North-South

The IPv8 security model splits things into “East-West (internal lateral movement)” and “North-South (internet egress).”

East-West Is Separated by ACL8 Zones

Lateral movement is blocked by three layers of ACL8:

ACL8 at the NIC firmware level
ACL8 at the Zone Server gateway
OAuth2 VLAN enforcement at the switch port

There’s also a note that the NIC enforces rate limits of 10/sec (unauthenticated) and 100/sec (authenticated) in hardware.
Broadcast is capped at 10/sec.
This direction of “put limits in layers that ordinary endpoint protection can’t touch” is clearly thinking about ransomware lateral movement.

North-South Requires DNS8 Resolution and WHOIS8 Validation

On the egress side, the next two checks are mandatory.

flowchart TD
    A[App initiates external connection] --> B[DNS8 name resolution]
    B -->|fail| X[Connection blocked]
    B -->|success| C[Identify destination ASN]
    C --> D[Validate destination ASN via WHOIS8]
    D -->|unregistered/fail| X
    D -->|success| E[Traffic allowed]

With this, “malware C2 that connects directly to a hardcoded IP” is killed at the protocol layer.
BGP8 route advertisements also won’t install unless WHOIS8 validation passes, so manual bogon filter maintenance becomes unnecessary, per the draft.

Device Conformance Tiers

The draft organizes equipment into three tiers.

Tier	Equipment	Required Features
Tier 1	End device	DHCP8, static routes, VRF management, NetLog8, ACL8
Tier 2	L2 switch	802.1Q trunks, auto-VLAN, PVRST, OAuth2 port binding, NetLog8
Tier 3	L3 router	Tier 1 + eBGP8, IBGP8, OSPF8, IS-IS8, XLATE8, WHOIS8 resolver

It specifies PVRST mandatory for spanning tree, with Zone Server as root. A pretty bold ask.
Even Tier 1 pulls in a NetLog8 client, which promotes “take consistent telemetry across the whole network” to a standard requirement.

A Migration Strategy with No Flag Day

IPv8 migration is incremental. No one has to switch “on the same day.”

Tier 1/2 ISPs update software
Cloud providers adopt internally
Enterprises optionally take an ASN prefix
Consumer ISPs migrate

Cases where an IPv8 island gets partitioned by an IPv4-only transit network are stitched together with an 8to4 tunnel encapsulated over HTTPS (prioritizing encryption and firewall traversal).
BGP8’s 8TO4-ENDPOINT attribute automatically advertises the tunnel endpoints, so you can open a hole with zero manual configuration, per the draft.

CGNAT boxes don’t need modification. IPv8-aware CGNAT translates only n.n.n.n while preserving r.r.r.r.

Application Compatibility

Existing IPv4 apps work without modification, the draft states.
The IPv8 socket compatibility layer transparently intercepts syscalls.

New apps can use AF_INET8 and sockaddr_in8 to handle ASN and host separately.
All the “per-app AF support and string parsing” headaches that plagued IPv6 are side-stepped up front by shaping it as an IPv4-format extension.

Digs at IPv6

Reading between the lines, the draft’s take on IPv6 is harsh. Paraphrased:

Forced dual-stack was the biggest wall to adoption
After 25 years, it still only carries “a minority of world traffic”
Having solved only address exhaustion, management-plane fragmentation and routing-table bloat were left untouched
IPv8 goes for single-stack and unified management at the same time

This isn’t a rebuttal of “IPv6’s technical elegance.” It’s more a systems-level critique that re-explains why IPv6 lost as a social implementation.

IANA Requests

IPv8 asks IANA for the following allocations.

IP version number “8”
127.0.0.0/8 (internal zone) and 100.0.0.0/8 (RINE) in the r.r.r.r range
Documenting 222.0.0.0/8 on the n.n.n.n side as internal link convention
A new DNS A8 record type
ASN 65534 (private peering) and 65533 (documentation)

As noted, the IPv8 version-number slot was once reserved for PIP during IPng deliberations, and was left open after PIP wasn’t adopted.

The Companion Draft Bundle

draft-thain-ipv8-00 isn’t alone. It moves together with a bundle of more than ten related drafts.

draft-thain-routing-protocols-00 (BGP8/OSPF8/IS-IS8/Cost Factor)
draft-thain-zoneserver-00 (Zone Server architecture)
draft-thain-whois8-00 (WHOIS8 validation)
draft-thain-netlog8-00 (telemetry format)
draft-thain-support8-00 (ARP8/ICMPv8/Route8)
draft-thain-rine-00 (Regional Inter-Network Exchange)
Plus MIBs, WiFi8, update, auth schemes, and more

Less “IPv8 the single protocol” and more a bundle of operational platform drafts predicated on IPv8, dropped all at once.
In contrast to IPv6, which funneled multiple candidates down to one through WG, IPv8 is pitching the full stack from day one: “adopt this whole thing, please.”

Personally, I strongly sympathize with the reframing of IPv6’s adoption failure as “operations and dual-stack social cost” rather than “address design.”
At the same time, demands like the /16 BGP floor, mandatory WHOIS8 validation, and mandatory PVRST / Zone Server read like they erode the sovereignty of existing AS operators and content providers. Getting this through a real standards process would carry a very high consensus-building cost.

Given that IPv6 was standardized only after three candidates competed and a WG reached consensus, a proposal at this scale landing solo as an individual draft is inherently unusual. The first thing to watch is whether a WG even forms.

The body of draft-thain-ipv8-00 expires in six months, so if you’re going to read it, read it soon.