HN Debrief

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

  • Infrastructure
  • Networking
  • Open Source
  • Security

The post describes a full working implementation of an “IPv8” Internet-Draft that proposes 64-bit addresses built from ASN.Host and folds a grab bag of functions like naming, time, logging, auth, and registry lookups into a single “Zone Server.” The team says they patched Linux 6.6 with an AF_INET8 socket family, updated musl, iproute2, FRRouting, Nginx, and curl, then ran a 10-node QEMU testbed with 112,000 routes to see whether the draft survives contact with something closer to a real network. Their conclusion is blunt: it works in a lab, but falls apart in the actual Internet because the 28-byte header breaks common MTU assumptions, routing and source-validation policies misfire on the addressing model, older switching silicon punts the new EtherType into slow paths, the all-in-one Zone Server becomes a giant blast radius, and the economics around registries and table growth get ugly fast.

Treat this as a useful stress test for protocol change, not a new networking direction. If you build networked products, the lesson is that compatibility failures live as much in deployed hardware, operational policy, and funding structures as in packet formats.

Discussion mood

Amused but dismissive. People enjoyed the stunt and respected the engineering effort, while treating the underlying IPv8 draft as a bad or fake spec whose main value is that implementing it exposed why it should not be taken seriously.

Key insights

  1. 01

    RIR funding is operational, not speculative

    The registry-collapse point lands differently once you remember what Regional Internet Registries actually fund. They are non-profit operators of shared Internet control-plane infrastructure like WHOIS, Resource Public Key Infrastructure trust anchors, and policy administration. The objection is not that somebody loses a revenue stream. It is that the institutions that keep address ownership and route authorization legible stop having money to run.

    When you evaluate protocol changes, include who pays for the boring control-plane machinery. If your design bypasses existing registries or shrinks their role, map out a replacement funding model before calling it simpler.

      Attribution:
    • turborigby #1
  2. 02

    IPv6-only already has an IPv4 bridge

    The missing piece for many “why can’t we just drop IPv4 at home” complaints is not a new protocol. It is NAT64 plus CLAT. NAT64 can transparently let IPv6-only clients reach IPv4 services, and CLAT covers apps that hardcode IPv4 literals instead of using DNS. That means the transition path people want mostly exists already. The gap is inconsistent deployment and poor visibility to users, not the absence of a mechanism.

    If you are designing client software or managed networks, test on NAT64 and 464XLAT environments now. Apps that assume raw IPv4 connectivity or bypass DNS still break in places where operators are already moving toward IPv6-first.

      Attribution:
    • wmf #1 #2
  3. 03

    IPv6 adoption is real but uneven

    Claims that IPv6 “hasn’t been adopted” do not survive contact with mobile networks and large content providers. Comments pointed to Google reporting over 50 percent IPv6 traffic globally on some periods, strong adoption in the US, and especially high use in places like France. The better read is that IPv6 succeeded in major access networks and content delivery, while still failing to remove IPv4 as a universal dependency.

    Do not plan infrastructure as if IPv6 is niche. Also do not assume IPv4 can be dropped. Product and network teams need both a real IPv6 posture and an explicit strategy for the long tail of IPv4-only dependencies.

      Attribution:
    • jrmg #1
    • adw #1
    • alexpotato #1
    • simoncion #1
  4. 04

    IPv6 was not blocked by a flag day

    The line that IPv8 has the “no flag day” property IPv6 should have had gets the history wrong. IPv6 was explicitly built for gradual deployment. The sharper criticism is that its conservative “ships in the night” coexistence model raised cost and complexity, which slowed incentives to finish the transition. That is a more useful diagnosis than pretending IPv6 demanded a single coordinated cutover.

    For migration design, gradual rollout is necessary but not sufficient. If coexistence is too comfortable or too expensive, organizations drag the transition out indefinitely.

      Attribution:
    • wmf #1
  5. 05

    The implementation claim is testable

    Skeptics questioned whether this was just AI-written theater. The response that matters is concrete. The author says there are patched source trees for Linux, musl, iproute2, FRRouting, curl, and Nginx, plus a QEMU mesh and route-scale tests. That does not validate the protocol, but it does make the experiment materially more valuable than a satire post or an LLM-generated essay because others can inspect and run the code.

    When someone makes protocol or systems claims, ask for runnable artifacts, not prose. Even bad ideas become informative when they are implemented deeply enough to hit real kernel, routing, and toolchain constraints.

      Attribution:
    • turborigby #1

Against the grain

  1. 01

    Dual-stack is not the main problem

    The strongest pushback on the anti-dual-stack complaints is that most users never touch the complexity, modern host firewalls are largely IP-version agnostic, and the stacks have been stable for years. From that view, dual-stack is not a pathological state to eliminate. It is a long-lived operational compromise that buys compatibility while address pressure gets pushed into carrier-grade translation.

    If you run consumer or enterprise networks, do not assume users benefit from an aggressive single-stack purity project. Focus first on making the coexistence path boring and supportable.

      Attribution:
    • simoncion #1 #2 #3
  2. 02

    Registry collapse is overstated

    One reply argues the economics section overreaches because Regional Internet Registries are not profit-seeking businesses. If their workload shrinks, they can shrink staffing too, and governments could fund the public-good parts if needed. That weakens the article’s framing of registry finance as a fatal obstacle on its own.

    Separate governance risk from technical impossibility. If a proposal depends on replacing institutions, the real question is whether the new stewardship model is politically plausible, not whether current fee structures are sacred.

      Attribution:
    • wmf #1

In plain english

AF_INET8 ↩
A proposed socket address family in the Linux networking API for this experimental IPv8 protocol, analogous to AF_INET for IPv4 and AF_INET6 for IPv6.
ASN ↩
Autonomous System Number, a unique identifier for a network that participates in interdomain routing on the Internet.
CLAT ↩
Customer-side translator used with 464XLAT to let devices or apps that assume IPv4 still work on IPv6-only networks.
DNS ↩
Domain Name System, the internet service that translates website names into network addresses.
EtherType ↩
A field in Ethernet frames that tells devices which protocol the payload contains.
FRRouting ↩
An open source routing software suite that implements protocols such as BGP for Linux and Unix systems.
iproute2 ↩
The standard Linux user-space toolset for configuring network interfaces, addresses, and routes.
MTU ↩
Maximum Transmission Unit, the largest packet size a network link can carry without fragmentation.
musl ↩
A lightweight standard C library often used in small, static, or security-focused Linux systems.
NAT64 ↩
A translation mechanism that lets IPv6-only clients communicate with IPv4-only services.
qemu ↩
An open source machine emulator and virtualizer often used to run virtual machines on Linux.
WHOIS ↩
A public query system and database used to look up registration information about domain names, IP address blocks, and Autonomous System Numbers.

Reference links

Traffic and adoption data

Background on IP version numbering

Project code and report