A few weeks ago, the "Internet Protocol Version 8 (IPv8)" Internet-Draft (draft-thain-ipv8-02) caught our eye. The draft proposes replacing IPv4/IPv6 with a 64-bit hierarchical structure (ASN.Host), giving every 32-bit ASN holder 4.3 billion host addresses and consolidating DHCP, DNS, NTP, Syslog, OAuth, and WHOIS into a unified "Zone Server".
Instead of just debating the theoretical viability on mailing lists, our team at goonhost.rocks decided to implement the entire specification from scratch to see what happens when you deploy it across a distributed multi-AS network.
We set up a 10-node QEMU multi-AS testbed across 4 Autonomous Systems, pushed 112,000+ active routes into the kernel FIB, and ran continuous traffic generation.
While it works smoothly in an isolated lab, our report highlights several fundamental real-world failure modes:
1. PMTU & Silent MSS Blackholing (28-byte IP header breaks 1500-byte MTU paths without 1452-byte MSS clamping).
2. Asymmetric uRPF / BCP 38 drops on multi-homed ASNs.
3. Legacy DC switch ASIC/TCAM incompatibility (EtherType 0x88B8 punts to CPU exception path).
4. Monolithic Zone Server DDoS blast radius.
5. Systemic economic crises: RIR funding model collapse (90% revenue drop) and global BGP DFZ table explosion (3M–5M+ routes).
Thanks for testing,
in year 2026, still IPv6 is not fully well utilized homes, corporates especially it is worse at clouds (AWS, GCP) if you not limit north to south, they are not good for east-to-west compared to telco providers.
For example, GCP uses IP forwarding for IPv6 real IP address is not allocated at machine. At some of the components which is EKS is not support every case at IPv6.
So IPv8 can be available around year 2300 I guess :) (i have not inspected v8 RFC yet)
If IPv6 were wholeheartedly "adopted" then I and most consumers would not require "dual-stack" at home. Dual-stack is a terrible curse and a hack. IPv4 NAT is likewise a curse and a hack. We are left with these legacy curses only because the world can't seem to adopt IPv6. You don't need to abolish IPv4 to do it, you just need to get AAAA records and support the protocol! If you run a server or a public network, and you're not reachable by IPv6 in 2026, you're part of the problem.
I would not need "a home LAN" at home; I would not need "Private IP address space"; I would not need NATing router technology; my router software and configuration would be far, far simpler if my devices were able to single-stack. I believe the source of a lot of connectivity errors and difficult Heisenbugs involve dual-stack problems.
My devices don't need lateral connectivity on the LAN except for the printer. I attempted shutting off IPv4 on the printer and it dropped off entirely. I can't understand that. It doesn't need to reach the outside world for any reason. My Chromebook and Android don't speak to each other, except for Quick Share, which shouldn't require IPv4 addressing.
Has anyone devised a protocol or scheme by which an IPv6-only device can seamlessly access IPv4-only devices through their ISP and not local support? In other words, opportunistically intercept connection attempts and interpose a tunnel? It seems like this would be a final component to just killing off IPv4, en masse, in people's homes.
There is no "IPv8". Any crackpot can submit an internet-draft to the IETF, and this person happened to call theirs IPv8. If the submitter actually read the draft rather than feeding it to the slop cannon, they would have realized it is also a LLM hallucination that someone uploaded to IETF.
I am fairly sure the authors do understand this (see: "Most network engineers would laugh this off as an April Fools RFC written by an enterprise architect on buzzword overdrive."). But since the proposal got a lot of attention, responding to it is a public service. And delegating this to an LLM arguably provides an accurate signal as to how much human attention the original proposal deserved :-P
The entire point of the experiment was to take this specific, absurd Internet-Draft (which indeed exists as an active submission) and see what happens if someone actually implements it to the letter instead of just hand-waving it away.
LLMs might be able to hallucinate RFC text, but they certainly can't compile a patched Linux 6.6 kernel with a working AF_INET8 socket family, patch musl/iproute2/frr, spawn a 10-node QEMU mesh, and route 112,000 active FIB entries under live traffic.
The source code and commit history are right there in the GitLab repos - feel free to pull the kernel tree and run the test suite yourself.
Feel free to sign up and deploy a VM - we are a very real VPS host!
Unlike boring corporate providers, we just actually have a sense of humor (or more accurately, the developer has overdosed on TikToks and brainrot reels).
Satirical branding doesn't mean the bare-metal servers or the kernel code aren't real.
I appreciate this. IPv8 is a terrible, terrible idea, and it’s good to see someone actually built it out to prove the depths of its terribleness. Well done.
Question for someone who knows more about this stuff than I do: Why don't the problems in the "economic collapse" section also apply to IPv6? Or do they, and we've only been saved by lack of adoption?
It's 2026 and we're turning troll/fake spec submissions into actual usable technology. What a time to be alive.
There's only one thing in the article I disagree with:
> RIRs (ARIN, RIPE, APNIC) Go Financially Bankrupt
This is purely an argument of pragmatism, rather than having any technical merit. If a system works, and meaningfully improves over another system, I couldn't care less that people aren't able to effectively monetize it.
We believe that it is not possible to have a "flag-day" form of
transition in which all hosts and routers must change over at
once. The size, complexity, and distributed administration of the
Internet make such a cutover impossible.
IPng is a new version of IP which is designed to be an evolutionary step
from IPv4. It is a natural increment to IPv4. It can be installed as a
normal software upgrade in internet devices and is interoperable with
the current IPv4. Its deployment strategy was designed to not have any
"flag" days.
If saying "we can't have/didn't do a flag day" in the design documents, and then not having a flag day, isn't enough to stop you from arguing that v6 should have been engineered without a flag day, I have to wonder what v6 could possibly have done to make you happy with it.
25 comments
[ 0.22 ms ] story [ 13.9 ms ] threadA few weeks ago, the "Internet Protocol Version 8 (IPv8)" Internet-Draft (draft-thain-ipv8-02) caught our eye. The draft proposes replacing IPv4/IPv6 with a 64-bit hierarchical structure (ASN.Host), giving every 32-bit ASN holder 4.3 billion host addresses and consolidating DHCP, DNS, NTP, Syslog, OAuth, and WHOIS into a unified "Zone Server".
Instead of just debating the theoretical viability on mailing lists, our team at goonhost.rocks decided to implement the entire specification from scratch to see what happens when you deploy it across a distributed multi-AS network.
What we built: - Linux Kernel 6.6: Native AF_INET8 (family 46) socket layer, 28-byte packet routing, and sysctl boundary filters. https://gitlab.turborigby.xyz/goonhost-experiments/linux - Musl Libc: sockaddr_in8, inet_pton8, getaddrinfo() resolver support. https://gitlab.turborigby.xyz/goonhost-experiments/musl - iproute2: Native `ip -8 route` and `ip -8 addr` CLI tooling. https://gitlab.turborigby.xyz/goonhost-experiments/iproute2 - FRRouting: BGP8 daemon with Multi-Protocol Extensions (AFI/SAFI). https://gitlab.turborigby.xyz/goonhost-experiments/frrouting - IPv8 Zone Server (Go): 10-protocol platform (DHCP8, DNS8 TYPE_A8 88, SNTP, NetLog8, OAuth8, WHOIS8, XLATE8). https://gitlab.turborigby.xyz/goonhost-experiments/zoneserve... - Nginx & cURL: Patched for 64-bit IPv8 HTTP traffic. https://gitlab.turborigby.xyz/goonhost-experiments/nginx https://gitlab.turborigby.xyz/goonhost-experiments/curl
We set up a 10-node QEMU multi-AS testbed across 4 Autonomous Systems, pushed 112,000+ active routes into the kernel FIB, and ran continuous traffic generation.
While it works smoothly in an isolated lab, our report highlights several fundamental real-world failure modes: 1. PMTU & Silent MSS Blackholing (28-byte IP header breaks 1500-byte MTU paths without 1452-byte MSS clamping). 2. Asymmetric uRPF / BCP 38 drops on multi-homed ASNs. 3. Legacy DC switch ASIC/TCAM incompatibility (EtherType 0x88B8 punts to CPU exception path). 4. Monolithic Zone Server DDoS blast radius. 5. Systemic economic crises: RIR funding model collapse (90% revenue drop) and global BGP DFZ table explosion (3M–5M+ routes).
Full research report: https://cdnnn.goonhost.rocks/IPV8_RESEARCH_REPORT.md
2, 4, 8 then 16.
Very nice.
So IPv8 can be available around year 2300 I guess :) (i have not inspected v8 RFC yet)
Eh. It took quite a long time, but even HN has a v6 address these days:
I would not need "a home LAN" at home; I would not need "Private IP address space"; I would not need NATing router technology; my router software and configuration would be far, far simpler if my devices were able to single-stack. I believe the source of a lot of connectivity errors and difficult Heisenbugs involve dual-stack problems.
My devices don't need lateral connectivity on the LAN except for the printer. I attempted shutting off IPv4 on the printer and it dropped off entirely. I can't understand that. It doesn't need to reach the outside world for any reason. My Chromebook and Android don't speak to each other, except for Quick Share, which shouldn't require IPv4 addressing.
Has anyone devised a protocol or scheme by which an IPv6-only device can seamlessly access IPv4-only devices through their ISP and not local support? In other words, opportunistically intercept connection attempts and interpose a tunnel? It seems like this would be a final component to just killing off IPv4, en masse, in people's homes.
LLMs might be able to hallucinate RFC text, but they certainly can't compile a patched Linux 6.6 kernel with a working AF_INET8 socket family, patch musl/iproute2/frr, spawn a 10-node QEMU mesh, and route 112,000 active FIB entries under live traffic.
The source code and commit history are right there in the GitLab repos - feel free to pull the kernel tree and run the test suite yourself.
Unlike boring corporate providers, we just actually have a sense of humor (or more accurately, the developer has overdosed on TikToks and brainrot reels).
Satirical branding doesn't mean the bare-metal servers or the kernel code aren't real.
There's only one thing in the article I disagree with:
> RIRs (ARIN, RIPE, APNIC) Go Financially Bankrupt
This is purely an argument of pragmatism, rather than having any technical merit. If a system works, and meaningfully improves over another system, I couldn't care less that people aren't able to effectively monetize it.