^IPv[468]$ (v2)

Disclaimer

Mind: it's a draft... so it's "work in progress." yada yada yada...

These are my thoughts on this draft which at the time of writing this is 1 day old.

But IPv6...?

IPv6 hasn't succeeded since its 1998 release - the draft itself acknowledges this directly: after 25 years of standardization and deployment effort, IPv6 still carries a minority of global internet traffic.

IPv8 aims to fix adoption by including IPv4 backwards compatibility. It also states that CGNAT will continue to work - which is probably necessary for the protocol to gain traction - but I'd have liked the spec to also make clear that CGNAT isn't required, and that NAT in general wouldn't be needed with IPv8. Without that, ISPs will just slap NAT in front of it anyway, same as with IPv6.

Address Space

The IPv8 Address Format is r.r.r.r.n.n.n.n, where r.r.r.r is the ASN and n.n.n.n is the host address. That gives 2³² (4,294,967,296) ASNs with 2³² host addresses each.

I'd argue r.r.r.n.n.n.n.n would be a better split: 2²⁴ (16,777,216) ASNs - more than enough - with 2⁴⁰ (~1.1 trillion) host addresses each.

The difference matters in practice. For an ISP with ~8 million (2²³) connected households:

512 hosts per household is not a lot. 4 billion ASNs is way too many. The balance is off.

Management Philosophy

The central operational concept is the Zone Server - an active/active paired platform running every service a network segment needs: DHCP8, DNS8, NTP8, NetLog8, OAuth8, WHOIS8, ACL8, and XLATE8.

DNS, NTP, WHOIS, ACL, XLATE - all make sense. OAuth for business networks is a nice touch. But centralized log collection (NetLog8) immediately raises questions about security and guest network isolation. What exactly gets logged? The draft doesn't define this yet, which is a problem I'll come back to.

Even/Odd Addressing - New in -01

Draft -01 formalizes something only hinted at in -00: the even/odd Zone Server model. Every subnet has two Zone Servers at .254 (even) and .253 (odd). Even-addressed hosts route via .254, odd-addressed hosts via .253. Dual-NIC hosts get one even and one odd address from DHCP8 - one per NIC - giving active use of both gateway paths simultaneously.

This is genuinely elegant. Redundancy and load distribution fall out of the addressing convention itself, with no stateful load balancer required. The A8 DNS record spec is updated accordingly: responses should be an even/odd pair so clients can open parallel streams across both paths. XLATE8 gets the same treatment - when an IPv4 client connects to an IPv8 host, the gateway distributes connections across both addresses transparently.

WHOIS8 - Now Explicitly Critical Infrastructure

In -00, WHOIS8 was a route validation mechanism. Draft -01 elevates it to critical infrastructure: BGP8 route acceptance is now conditioned on a valid WHOIS8 record. No valid record, no route.

The right architectural call - but it raises a question the draft doesn't answer: what is the failure model? Who runs WHOIS8? What happens when it's unreachable? If it's as central as the spec implies, its governance is at least as important as the routing protocols themselves. This is the most consequential open question in the suite right now.

CGNAT

The draft states CGNAT will continue to work - probably necessary for adoption. But I'd have liked the spec to also make clear that CGNAT isn't required, and that NAT in general wouldn't be needed with IPv8. Without that explicit statement, ISPs will just slap NAT in front of it anyway, same as with IPv6.

Cost Factor (CF) Routing

One of the more interesting parts of the draft is the Cost Factor metric - it combines EIGRP's dynamic composite path quality, OSPF's accumulated cost model, and proportional load balancing in a single open versioned algorithm that operates end-to-end across AS boundaries.

The physics floor is a neat idea: no path can appear better than the speed of light over the great circle distance allows, giving you anomaly detection essentially for free.

Questions I have: CF is measured from TCP session telemetry - what happens with encrypted traffic? And there's a more fundamental problem:

Net Neutrality - Bought Into the Route

CF accumulates across every BGP8 hop. One of its seven components is explicitly economic - carriers feed their own peering costs into the algorithm, and the lowest accumulated cost wins.

This means money flows directly into routing decisions, by design. A carrier that charges more for a route to a competitor's CDN, or less for traffic to a preferred partner, isn't breaking any rule - they're just setting their economic policy component. Traffic shaping becomes invisible, automatic, and architecturally legitimate.

In the current internet, net neutrality violations require active intervention and are at least detectable. With CF, preference is just... the metric. It's structurally the same net neutrality debate, except buried three layers deeper in the stack where regulators are unlikely to look.

Censorship - A Dictator's Wishlist

This section was only added in v2 because I needed time to think through how to frame it.

IPv8 solves real problems. It also hands a lot of power to anyone who wants to control what their citizens access online.

The WHOIS8 routing dependency is the sharpest edge: no valid record, no route. A state controlling its WHOIS8 resolver can simply unroute destinations it dislikes - no firewall rules, no BGP poisoning, just stop validating the record and the site vanishes at the routing layer.

The Zone Server then becomes a single compellable point of control for an entire network segment - DNS8, ACL8, NetLog8, OAuth8, all in one place. One court order (or phone call) and filtering is universal and automatic for every device in the zone.

NetLog8 (still undefined) and the mandatory DNS8 lookup for every outbound connection together provide the infrastructure for a complete internet activity log, built into the base spec.

None of this is the author's intent. Good engineering and dangerous architecture aren't mutually exclusive. But IPv8 would make censorship a first-class feature of the network layer rather than something bolted on top. That conversation needs to happen in the working group before this goes much further - otherwise I'll rip it out or try to break it on any network I have access to.

Conclusion

The even/odd model in -01 is a real improvement - the kind of thing that looks obvious in hindsight. The WHOIS8 elevation to critical infrastructure is architecturally correct but needs a governance and failure-mode story before this can be taken seriously as deployable.

This whole thing still feels like an April Fools RFC... everything authorized via OAuth2 JWT? Pricing in the routing? WTF?

Four open problems:

1. NetLog8 is undefined (and it matters a lot for the censorship analysis above)
2. Address split - 4 billion ASNs makes no sense; shift octets toward the host side
3. Net neutrality - the economic CF component is a structural problem, not a config option
4. WHOIS8 governance - the spec can't stay silent on this much longer