Solutions

Industries

Why IPbnb

Company

Resources

Solutions

Industries

Why IPbnb

Company

Resources

IPv8: The Internet Protocol That Could Give Governments the Perfect Censorship Tool

A new IETF draft wants to fix everything wrong with IPv4. The architecture it proposes might fix something governments were never supposed to have.

Artem Kohanevich

Artem Kohanevich

Co-Founder & CEO at IPbnb

Last updated

11

min.

Reading time

Table of Contents

item

ipv8 internet protocol
Ask AI to explain
Open this article in your AI assistant for a quick summary.

Every few years, someone publishes a proposal to replace the internet's addressing system. Most of them quietly expire. The one that landed on April 14, 2026 - a draft titled "Internet Protocol Version 8" by Jamie Thain of One Limited - is different, not because it will succeed, but because the concerns it raises are worth taking seriously before similar ideas appear in a proposal that does.

At IPbnb, we operate in the IPv4 address market. We think carefully about how IP addressing works, who controls it, and what changes in that architecture mean for the people and organizations that depend on it. IPv8 touches all three. Let us walk through what it actually proposes, why the community is skeptical, and why one specific aspect of its design deserves more attention than it has received.

First, a Disambiguation: There Are Three Things Called "IPv8"

Before anything else, a necessary clarification. The term "IPv8" currently refers to at least three unrelated things.

The first is py-ipv8, a working peer-to-peer framework developed by TU Delft and used in the Tribler project. It runs over UDP, uses Curve25519/Ed25519 cryptographic identities instead of IP addresses, and has been in active development since 2018. The name is, by the developers' own description, a decade-long joke about IPv6's slow adoption. It has nothing to do with replacing TCP/IP.

The second is the original historical IPv8 - a protocol called PIP, proposed by Paul Francis of Bellcore in 1992 and documented in RFC 1621 and 1622. PIP competed in the IETF's "IPng" process against what eventually became IPv6, and lost in July 1994 because its variable-length addresses were difficult to process in hardware. It was formally moved to Historic status in 2016.

The third - and the one generating all the current discussion - is draft-thain-ipv8, an individual Internet-Draft submitted to the IETF in April 2026. This is what the rest of this article is about.

What Draft-thain-ipv8 Actually Proposes

The draft sets out to solve three problems simultaneously: IPv4 address exhaustion, fragmented network management, and uncontrolled growth of the global BGP routing table.

The address format is a 64-bit address written as r.r.r.r.n.n.n.n - eight octets instead of four. The first 32 bits encode an ASN (Autonomous System Number); the last 32 bits are a conventional host address, identical in semantics to IPv4. The critical backward-compatibility claim is this: if the ASN prefix is 0.0.0.0, the address is an IPv4 address, processed by standard IPv4 rules. No modification to existing devices or applications required.

Each ASN holder under this scheme receives 2^32 host addresses - over four billion - which means address exhaustion becomes a non-issue at any organizational scale. The global BGP routing table, currently exceeding 900,000 prefixes with no structural bound, would be capped at roughly one entry per ASN (approximately 175,000 today) because deaggregation below /16 is forbidden.

The packet header is 8 bytes longer than IPv4 - the source and destination address fields each grow from 32 to 64 bits. Everything else (TTL, Protocol, Flags, Checksum) stays the same.

The Zone Server is the architectural centrepiece. It is a mandatory, active/active platform that consolidates every service a network segment needs: DHCP8, DNS8, NTP8, authentication (OAuth8), route validation (WHOIS8), access control (ACL8), telemetry (NetLog8), and NAT translation (XLATE8). A device joining an IPv8 network sends one DHCP8 request and receives, in one response, all service endpoints it needs. Authentication is via OAuth2 JWT tokens validated locally, without round trips to external identity providers.

The routing improvement is the Cost Factor (CF) - a 32-bit accumulated metric derived from seven components: round-trip time, packet loss, congestion window state, session stability, link capacity, economic policy, and geographic distance as a physics floor. The geographic component is notably elegant: no path can appear better than the speed of light over the great-circle distance allows, so a path that measures faster than physics permits is immediately flagged as anomalous.

Transition is designed to require no flag day. An 8to4 tunnelling mechanism - encapsulated over HTTPS so it traverses firewalls without configuration - allows IPv8 islands to communicate across IPv4-only transit networks.

Why The Technical Community Is Skeptical

The criticism has been pointed and mostly consistent across HackerNews, The Register, LowEndTalk, and specialist networking blogs.

The process gap is glaring. IPv6 emerged from a multi-year competitive process inside the IETF, where three serious candidates (CATNIP, TUBA, and SIPP) were evaluated by a working group before SIPP was selected and extended to 128 bits. Draft-thain-ipv8 arrived as a single individual submission - no working group, no prior competitive process, no institutional sponsorship. The IETF datatracker page itself states it is not endorsed by the IETF and has no formal standing. It expires October 19, 2026 unless renewed or adopted by a working group, and neither looks likely.

The OSI violation is fundamental. IPv8 moves OAuth2 and JWT authentication - mechanisms that belong at Layer 7 of the OSI model - directly into the network layer (Layer 3). Most network devices (access switches, industrial controllers, basic routers) are not designed to perform application-level authorization. The argument that this is a feature, not a bug, does not address the hardware reality. That said, we at IPbnb tend to read this more optimistically than most critics do: hardware is not static. Providers refresh their infrastructure every seven to ten years anyway, driven by capacity demands, fiber rollouts, and generational upgrades like DOCSIS 3.1 and Wi-Fi 6. If IPv8-capable hardware simply becomes the next generation of that equipment, the OSI objection shifts from a blocker to a timeline question.

The real issue is not whether devices can be replaced - they can and will be - but whether there is enough ecosystem pull to make IPv8 capability a requirement in the next generation rather than an optional feature nobody ships.

The backward-compatibility claim has a hard limit - but a more nuanced one than it first appears. The blunt version of this criticism goes: every router, switch, and ASIC validates the Version field in the IP header and drops anything that doesn't read 4 or 6. A packet marked Version 8 dies at the first hop. That is accurate. But it misses something important about how IPv8's architecture actually handles the transition.

The XLATE8 mechanism - built into every IPv8 Zone Server - is designed to translate between IPv4 and IPv8 at the gateway level. A legacy device behind an IPv8-capable home gateway or ISP edge router never sends a Version 8 packet at all: it sends standard IPv4, XLATE8 wraps it, and IPv8 takes it from there. The billion-plus endpoint devices - phones, laptops, smart TVs - don't necessarily need to be replaced. What does need to be replaced is the CPE and provider infrastructure sitting between them and the internet. And here, the hardware refresh picture is less dire than critics suggest: ISPs shipped approximately 180 million CPE units globally in 2024 alone, and telecom operators invested over $35 billion in hardware upgrades between 2022 and 2025, driven by fiber and 5G rollouts. If future CPE generations ship with IPv8 capability - which is a business and regulatory question, not a physical impossibility - the gateway transition happens largely on natural cycles without touching user devices at all. The harder cases are devices that connect directly to the network without passing through an IPv8-capable gateway: mobile handsets on cellular baseband chipsets, IoT devices on direct cellular connections, and enterprise hardware outside ISP-controlled infrastructure. These follow different and slower replacement cycles.

More fundamentally, the entire argument rests on XLATE8 working as transparently in practice as the specification claims - a strong assumption that no real-world implementation has yet tested.

The AI authorship question. Analysis using GPTZero reportedly indicated approximately 76% probability that substantial portions of the text were AI-generated. Thain has acknowledged using AI assistance and considers it standard practice. The technical community's concern is not about the tool but about whether the proposal reflects genuine engineering experience with the problems it claims to solve.

The IPv6 timing is awkward. On March 28, 2026 - just two weeks before the draft appeared - global IPv6 traffic measured by Google crossed 50% for the first time, 32 years after the IPng process began. The draft's central premise that "IPv6 failed" is significantly harder to sustain today than it was even a year ago..

The Censorship Problem - And Why It Matters More Than The Technical Critique

All of the above criticisms are legitimate. But there is a concern that has received less systematic attention, and it is the one that should give the broader internet community the most pause.

IPv8's security architecture is built around a set of interlocking mechanisms, each individually defensible, that together create the most capable censorship and surveillance infrastructure ever embedded in an internet protocol specification.

Here is how it works in practice.

DNS8 as an inescapable gate. On today's internet, DNS-based blocking is the weakest form of censorship. Users can switch from their ISP's resolver to 8.8.8.8, 1.1.1.1, or any open resolver in seconds. DNS blocking is trivially bypassed. Under IPv8, DNS8 is not a resolver you can replace. It is the Zone Server, and the Zone Server is the mandatory egress point for all traffic. There is no "use a different DNS server." If the Zone Server does not resolve your destination, your connection is blocked at the gateway before the packet leaves your network - not at the far end, not at a border router, but at your own mandatory local infrastructure.

WHOIS8 as a global registry kill switch. Every outbound packet's destination ASN must appear in the WHOIS8 registry as a legitimately registered active route. If it does not, the packet is dropped. More critically: at the global BGP8 level, routes that cannot be WHOIS8-validated are never installed in routing tables at all. This means blocking a resource does not require DPI, DNS tampering, or border filtering. A government that controls, or can pressure, the relevant Regional Internet Registry needs only to ensure a target ASN's prefix is absent from WHOIS8. No record - no route - no reachability, enforced at the protocol layer across every network that implements IPv8.

OAuth2/JWT: the end of anonymous connections. Every managed device must authenticate via a JWT token before sending its first packet. The protocol is explicit: anonymous connections at the IP level cease to exist. This is designed to eliminate malware command-and-control channels - a real problem. But it simultaneously eliminates the anonymity that makes Tor, VPNs, and privacy tools effective. A government holding the identity infrastructure (or able to compel operators who do) gains the ability to attribute every connection to a specific authenticated identity.

NetLog8: surveillance built into the spec. Mandatory real-time telemetry collection is not an optional feature. It is required at every Zone Server. Every authentication, every connection, every policy violation is logged and timestamped. This is presented as network observability for operators. It functions equally well as a comprehensive traffic surveillance record for state actors.

The draft contains no governance framework for who controls the Zone Server. It contains no specification of what oversight governs WHOIS8 record removal. It contains no mechanism for judicial review of ACL8 rules or JWT revocation. These are assumed to be operated in good faith by legitimate network administrators.

That assumption does not survive contact with political reality in a large portion of the world.

The comparison to Huawei's "New IP" proposal is instructive. In 2020, Huawei submitted to the ITU-T a proposal called "New IP" that would have enabled per-packet, authenticated, government-controllable filtering at the network layer. It was rejected by the internet governance community - including IETF leadership, the Internet Society, and multiple governments - precisely because it would have built censorship capability into the protocol itself. IPv8 achieves structurally identical outcomes through different technical mechanisms, apparently without its author intending this reading. The intent does not change the architecture.

To be direct: today, building a national censorship system requires enormous investment in overlay infrastructure. The Great Firewall of China, Russia's СОРМ, Iran's national intranet - these are expensive, technically demanding systems that have to fight against a protocol designed for openness. IPv8 inverts this relationship. Under its architecture, the open internet would be the overlay. The controlled, authenticated, logged, gateway-validated network would be the base layer.

What This Means For The IPv4 Address Market

For those of us working in IPv4 address leasing and trading, IPv8 in its current form represents no immediate market risk. The draft will almost certainly expire in October without working-group adoption. No major vendor, carrier, or RIR has expressed support.

The deeper question is whether the ideas in IPv8 find their way into future proposals that do gain traction. The routing table problem IPv8 identifies is real. The management fragmentation problem is real. The address exhaustion problem, while partially addressed by IPv6's continuing deployment, remains acute for organizations that cannot afford the operational cost of IPv6 transition.

If future proposals inherit IPv8's ASN-centric addressing logic - including the concept that each ASN holder receives a large private address block - the consequences for the secondary IPv4 market would be significant. The value proposition of leased IPv4 addresses depends on address scarcity and the operational cost of IPv6 transition. An architecture that eliminates both, while maintaining IPv4 backward compatibility, would directly affect that market.

That scenario is speculative and distant. What is not speculative is the censorship architecture embedded in IPv8's design. Whether or not this specific draft advances, the pattern it represents - consolidating DNS resolution, identity authentication, route validation, and traffic logging into a single mandatory platform - will reappear in future proposals. When it does, the question of who controls that platform will be the most important question to ask.

A managed IPv4 leasing marketplace for holders

Monetize IPv4 Without Selling the Asset

Conclusion

Draft-thain-ipv8 is unlikely to become a standard. Its technical shortcomings, process failures, and the awkward timing against IPv6's deployment milestone make adoption improbable. But it is a detailed, technically ambitious proposal that forces genuinely important questions into the open: Can management fragmentation be solved at the protocol layer? Can BGP table growth be architecturally bounded? And most importantly - can any protocol that achieves mandatory, universal, authenticated, logged traffic control ever be trusted to be operated in good faith by every government on earth?

The answer to that last question is the reason the end-to-end principle matters. An internet where every connection is attributed, every destination is pre-validated against a government-accessible registry, and every packet passes through a mandatory platform controlled by whoever holds the infrastructure is not a more secure internet. It is a more controlled one. That distinction is worth preserving, regardless of how elegant the address format is.

Artem Kohanevich

Artem Kohanevich

,

Co-Founder & CEO at IPbnb

Artem is a serial entrepreneur who scaled GigaCloud into Ukraine's leading IaaS provider. Now building IPbnb - a global platform for secure IPv4 rent, sale, and management.

Ready to Make IPv4 Work for You?

Whether you're monetizing idle blocks or need clean IPs fast – IPbnb handles the complexity so you don't have to.

Ready to Make IPv4 Work for You?

Whether you're monetizing idle blocks or need clean IPs fast – IPbnb handles the complexity so you don't have to.

Ready to Make IPv4 Work for You?

Whether you're monetizing idle blocks or need clean IPs fast – IPbnb handles the complexity so you don't have to.

Ready to Make IPv4 Work for You?

Whether you're monetizing idle blocks or need clean IPs fast – IPbnb handles the complexity so you don't have to.