Show HN: We Implemented the IPv8 Internet-Draft in Linux, Libc, and BGP | Hacker News Reader

Show HN: We Implemented the IPv8 Internet-Draft in Linux, Libc, and BGP

goonhost.rocks

73 pointsturborigby69 comments

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.

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.

There's precedent, IP over Avian Carriers was tested back in 2001.

I think it's kinda cool to see how things would pan out instead of just plain theorycrafting - even if this isn't a serious proposal, it can be a start of one.

RIRs (RIPE NCC, ARIN, APNIC, etc.) are non-profit membership organizations, not commercial entities trying to "monetize" IP addresses.

Their registration fees directly fund critical global Internet infrastructure: the WHOIS databases, RPKI trust anchors, root DNS servers, and policy governance. If their operational budget collapses by 90%, it's not a loss of "profit" - it means there is literally no one funded to maintain the authoritative registry of who owns which ASN and route origin authorizations.

And even setting governance and economics aside, the technical failure modes remain fatal: 28-byte header PMTU blackholing, uRPF collisions on multi-homed links, and ASIC slow-path punting on existing linecards.

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)

IPv8 is just a reactionary response to IPv6 not being "IPv4 with larger addresses" like people who know IPv4 well would prefer.

There would be no reason to adopt it if IPv6 were adopted.

Imo the insistence on 'no NAT' has killed IPv6, as it made talking to legacy IPv4 nodes very awkward. If it could interop well with v4, then the transition wouldn't be all or nothing.

And it turns out the simplicity of 'no NAT' still buys you nothing. It's very common for modern systems to run multiple network interfaces with connections having to be juggled between them. In that case, connection and session management falls to a higher level protocol, often in the application.

Hrm, but the insistence is more "NAT should not be a practical requirement in a pure IPv6 network", not "No NAT ever for any reason".

NAT-based compatibility strategies are widely deployed in the real world (most cell carriers and Google's IPv6-mostly corporate network use NAT to allow communication with the IPv4 world from IPv6 only devices).

NAT is accepted for transition purposes; for example NAT64 makes it trivial to connect from v6-only clients to v4 servers, and is used by some large ISPs (e.g. T-Mobile in the US) to avoid running v4 inside their access network.

Yet IPv6 hasn’t been adopted. For decades.

Because it wasn’t implemented transparently at the OS. I can’t plug in to my ip6 only network and reach an ip4 address because end user OSes don’t implement clat transparently, even today in 2026, let alone 20 years ago.

Yet IPv6 hasn’t been adopted.

Well over half of Google’s traffic is IPv6 in the USA, and it’s recently become over 50% of all Google’s traffic worldwide at weekends.

https://www.google.com/intl/en/ipv6/statistics.html#tab=per-... https://www.google.com/intl/en/ipv6/statistics.html

> Yet IPv6 hasn’t been adopted.

news to literally anyone on a mobile internet connection (which is most internet connections!)

Yes you can able to see IPv6 at your browser, but actualy there is always middlewhere sofware level (NLB, ALB, NAT) to reach real backend server, which creates bottle neck. For large scale enterprises this creates issue, even for cloudproviders, I have encountered bottle neck at some Major cloudprovider which causes snowball impact to whole cluster retry mechanisms and 4 hours outage for us and some other customers :D if the 2 enterpise has machine to machine IPv6 connectivity, this is will not happend.

I’m on 4g

My v6 endpoint is unreachable. My v4 one is fine.

I learned recently that France IPv6 adoption is also very high.

> Yet IPv6 hasn’t been adopted. For decades.

I'd argue it has, but that's not the point. IPv4 is pretty much mandatory for most users of the internet. Yes, individual users probably neither know nor core whether they're on IPv4 or IPv6, but it's so difficult to run IPv6-only that you just wouldn't bother.

Trying to teach someone about how to use ULA vs. GUA only leads to headaches. In fact, I'd go so far as to say the reason why the internet became so ubiquitous was because of NAT -- static internal addressing is pretty much fundamental to an easy-to-use experience. Having multiple addresses on a host only makes things far more confusing, so people don't bother, because IPv4 just works.

> ...in year 2026, still IPv6 is not fully well utilized...

Eh. It took quite a long time, but even HN has a v6 address these days:

  $ dig +short news.ycombinator.com ANY
  2606:7100:1:67::26
  209.216.230.207

That's great! I still don't, on any residential carrier I can purchase from.

> I still don't, on any residential carrier I can purchase from.

That's a bummer!

Contrariwise, this USian has had solid IPv6 service from every ISP I've gotten residential service from for more than a decade now.

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.

> If IPv6 were wholeheartedly "adopted" then I and most consumers would not require "dual-stack" at home.

Nah. We're not going to shut down IPv4 service for many, many decades. IPv6 is primarily an global-address-space-pressure-relief mechanism. In the next five, ten, fifteen years, enough end-user sites will have IPv6 GUA service that putting every end-user behind an IPv4 CGN and reducing the IPv4 GUA to end-user ratio to 50:1 or more will be a quite reasonable thing to do.

Any complaints you have about what you believe to be added complexity are mooted by one or more of the following:

1) End-users typically plug the magic internet router into the ISP-provided magic internet cable or box. They then magically get internet access in their house. They typically have no understanding of how any of this works.

2) Because the firewalls provided by Windows and OSX primarily care about which application is doing the network traffic, they're inherently IP version agnostic. I know that on the Linux side of things, nftables has been available for a decade and -by default- gives zero shits about the IP version of the traffic it's inspecting. So, for the three major consumer OSs it's easy to write firewall rules exactly once and have them apply regardless of what version of IP carries the traffic.

3) The major IP implementations were written years ago. That work's already been done. Removing one of those stacks is even more work.

a protocol or scheme by which an IPv6-only device can seamlessly access IPv4-only devices

NAT64 which is used extensively in cellular networks.

It is unclear whether this requires cooperation or knowledge on the IPv6-only side. It says it can be deployed to service providers. Do my IPv6 clients need to be NAT64 aware to participate? Or can this be transparently implemented to furnish IPv4 connectivity where normally it would just be an error? That's the sort of model I'm thinking of.

NAT64 is transparent and requires no support on the client side. The client does need a CLAT to use 464 for apps that connect to IPv4 addresses without using DNS.

> Dual-stack is a terrible curse and a hack.

Odd.

Is the IPX + IP dual stack a terrible curse and a hack? [0]

IP + Ethernet? [1]

[0] If you think this isn't real, you're not old enough.

[1] Given that your focus is home networks, other than "legacy baggage" there's zero reason that switches and IP implementations couldn't eliminate Ethernet addresses and use IP as their lowest logical layer. Switches already have to maintain a "MAC address -> switch port" lookup table. Converting that to an "IP address -> switch port" lookup table is easy. With the removal of Ethernet addresses, the need for ARP is eliminated, so there's no need for hosts to remember MAC addresses. Things are much simpler without all that legacy baggage, don't you agree?

Eliminating MAC addresses is a novel idea. I have not seen it credibly suggested before. Surely some functionality would be lost? Surely you'd at least need to redesign all Ethernet controllers around it?

Anyway, IPX, and Ethernet MAC, are different protocols with unique aims. I guess IPX was routable. But it was proprietary; it was Novell's baby, and it was serving a particular purpose for their software and network architecture. There was no sin in running it parallel to IP stacks.

The sin in dual-stack IPv4 + IPv6 is that they're the same protocol. There is nothing different in their aims, their reach, their utility or their transit networks. They're all serving the same Internet purposes, and the same protocols are both on top and below them, layer-wise. Same old TCP, UDP, QUIC, etc.

So, the only reason 4 and 6 coexist is transitional support. The only reason 4 still needs support and dual-stacking is because of a lack of 6 support. When/if IPv6 is wholeheartedly embraced, then dual-stacking is obsolete.

I'd like to reiterate that dual-stacking is an administrative pain and possibly the source of some really crazy connectivity bugs. A dual-stack system is unnecessarily complex. Eliminating Ethernet and MAC addresses is a revolutionary idea that would simplify things. But today, it is realistic to eliminate IPv4 just by widening support for v6. And that's something we should be working towards.

When/if IPv6 is wholeheartedly embraced, then dual-stacking is obsolete. ...dual-stacking is an administrative pain and possibly the source of some really crazy connectivity bugs. A dual-stack system is unnecessarily complex.

I don't think anybody really disagrees with this but it's kind of pointless to mention because there is no alternative. IPv8 would also require a period of dual-stacking.

T-Mobile is already running 99% single-stack IPv6-only so I would say the transition works; it's just a matter of doing it.

> I'd like to reiterate that dual-stacking is an administrative pain...

This professional administrator disagrees.

> The sin in dual-stack IPv4 + IPv6 is that they're the same protocol. There is nothing different in their aims, their reach, their utility or their transit networks.

That same commentary applies to IP + IPX. Your understanding of IPX is poor. This was about the depth of analysis I was expecting. Pity.

> Eliminating MAC addresses is a novel idea. I have not seen it credibly suggested before. Surely some functionality would be lost?

No more than eliminating IPv4 addresses in the far future, and far less if that elimination was done today. Go read up. It'll probably take you a few weeks to get up to speed.

> But today, it is realistic to eliminate IPv4 just by widening support for v6.

lol.

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?

For one thing, RIRs are not businesses. If they have less work to do they can have less staff. Worst case they could receive government funding like in the old days.

Would they in fact have less work to do? Government funding might be the right answer, but it's not necessarily going to happen automatically; the concern (which applies in other domains besides this one) is disrupting the means by which a public good is currently funded, without having a replacement already lined up.

Also there's a subsection about tier 1 networks and those are businesses.

Thanks for going through the work of testing this. Better to have the actual results for a joke than to joke about theories :)

isn't any ipv6+ supposed to use any string address and no DNS is required at all? :D

The "no flag day" is how ipv6 should have been engineered.

It was engineered like that. It was known from the start that having a flag day wasn't possible (https://datatracker.ietf.org/doc/html/rfc1726#section-5.5):

  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.

And when they picked a design, it indeed didn't have a flag day (https://datatracker.ietf.org/doc/html/draft-hinden-ipng-over...):

  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.

IPv6 never had flag days and was specifically designed for gradual deployment. In retrospect, overly conservative "ships in the night" routing increased costs and delayed IPv6 deployment though.

Did you implement it, or did Claude implement it?

I'm pretty sure an AI wrote all or most of this article.

Where is IPv7?

I have that RFC on my iPhone 9

It's like how we skipped from Windows 95 to Windows 98

I think those were release years. More like how we went from Windows 8 to 10.

(I understand that the real reason here is either a) OSX went to version 10, so don't want to be behind, or b) many systems would pattern match on windows version 9*" so Windows 9 would be treated as 95/98.)

Examples of B were found in open source, including some versions of the OpenJDK.

Mac OS was said to skip 9 on the way to 10 due to a combo of some Asian numerology (just as Western numerology often encourages skipping "unlucky" 13) and also trying to make a clean break more obvious between System 8 and OSX. (The X being the 10, as Apple's favorite way to write 10 for various reasons. Which is why "OSX" was always a misnomer, accidentally burning the version number into the operating system name. Part of why Apple has been trying to get everyone on the "macOS" brand lately to pull the version number back out.)

https://en.wikipedia.org/wiki/Mac_OS_9

Uh, Mac OS 9 existed. It shipped with early iMacs before OS X was stable and for people who needed to run old apps natively.

It goes up in powers of two.

2, 4, 8 then 16.

Very nice.

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

This. While I'm generally opposed to using LLMs to make changes in critical parts of systems, a vibed spec just naturally prompts a vibed implementation.

OpenPGP key servers are an internet draft, if memory serves. I guess they don't exist either.

In fairness, they exist by virtue of having working implementations that (at least a few) people actually use, not by virtue of being an Internet-Draft.

SCEP was (and still is) a very deployed protocol yet took 20 years for the draft to be published...

It is not an individual I-D, but has been adopted by a working group, and has a chance of actually being published as a RFC.

they are disgustingly slow so maybe we need a new draft...

Worse, there is an IPv8, from 1994, the obsolete P internet protocol (PIP) https://en.wikipedia.org/wiki/List_of_IP_version_numbers

There was also a second prior "IPv8" proposal from a couple years later by notorious mailing list troll Jim Fleming, which he subsequently expanded to "IPv16"

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.

Can't they? I thought this kind of thing was within Fable's capabilities.

This is absurd and I love it.

Hey HN,

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.

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

Your Markdown-format research report is full of mojibake, you might want to fix that.

Fixed the Content-Type header on R2 CDN, the UTF-8 box-drawing diagrams should render cleanly now. Thanks for pointing it out!

Seems to be a 404 now.

The whole site appears to be satire, based on the homepage. I think we can ignore this article of theirs as well.

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.

What’s wrong with satire sites? If The Onion put in the work to try this, I’d still be interested in hearing about it.

It’s true that satire is not always bad. But I dislike that they don’t make it obvious that this article is satire. It wastes people’s time who actually take it seriously (as we can see by the other HN comments). Or if it’s serious, then why is it on a satire site? They need to pick a lane and be clear about it.

It wasn't clear to me that this was a satire article. It seemed like a reasonably serious experiment with a bad idea.

Reply on news.ycombinator.com