By which I mean to insinuate there's a lot of nuance and learned lessons in the current situation that this design seems not to learn from. Even though it did learn some lessons, I don't think this passes 'Chestertons fence'

But more seriously, it gives me a pause when we try to bake more complex, application-centric logic into foundational protocols. The list of assigned IPv4 and TCP option numbers is a graveyard of tech experiments, but at least we had the sense to separate them from the main protocol. Baking JSON web tokens and OAuth into IP seems kinda crazy from that point of view. Is this what we want to commit to for the next 40 years?

I kinda wish that IPv6 just used this ("IPv8") addressing scheme and left everything else the same, though. I think the expectation that IPv6 should entail an architectural rethink for existing networks really slowed us down. Fun fact: at this point, IPv6 is 30 years old, we're still under 50%, and growth is visibly tapering off.

The whole thing isn't a joke because of this. Technically, it's IPv4++ and that about it.

> Every manageable element in an IPv8 network is authorised via OAuth2 JWT tokens

What ?!

I'm not sure it's the path I want to follow.

https://datatracker.ietf.org/doc/draft-thain-ipv8/

I must be missing something or misinterpreting that section because if there is no "lateral movement" how do people in an office print a file, access a network drive, connect to the Exchange server? And those are only the most naive scenarios.

How is this different from IPv6? We've had 6to4 for ages, the problem is the other direction: how does a IPv4 host initiate a connection to a IPv8 host?

Existing IPv4 applications use the standard BSD socket API with AF_INET and sockaddr_in. The IPv8 compatibility layer intercepts socket calls transparently -- the application has zero IPv8 awareness.

Except many IPv4 applications use the addresses of the source or that they bind to in some form. If it's secretly an IPv8 behind their back that'll break.

"IPv4 is a proper subset of IPv8. No existing device, application, or network requires modification. 100% backward compatible."

This cannot be true. Section 5.1 states that IPv8 uses version number 8 in the IP header Version field and the header is 8 octets longer than IPv4's. Any existing IPv4 router, switch ASIC, NIC, host stack, or firewall that sees a Version=8 packet will fail to parse it (most will drop it). Backward compatibility is logically impossible when the wire format is different.

The spec simultaneously demands sweeping new machinery everywhere: new socket API (AF_INET8), new DNS record type (A8), new ARP (ARP8), new ICMP (ICMPv8), new BGP/OSPF/IS-IS, mandatory certified NIC firmware with hardware rate limits, mandatory Zone Servers, mandatory OAuth2 on switch ports, mandatory persistent TCP/443 to the Zone Server from every end device, and a new IANA version-number assignment. "No modification required" is contradicted on nearly every page.

IP version 8 is already historically assigned (it was PIP, later folded into the IPv6 effort). The draft's IANA request ignores this.

The ASN model conflates identity with location. ASNs are organizational identifiers assigned by RIRs, turning them into the 32-bit routing prefix means an organization cannot change providers, multihome with provider-assigned space, or use PI space the way networks do today. Every organization that wants public IPv8 connectivity must now hold an ASN - roughly a 1000x increase in ASN allocation.

The /16 minimum injectable prefix rule eliminates essentially all of today's BGP traffic engineering and most multihoming patterns.

Cross-AS Cost Factor (CF) requires every AS on Earth to trust the metrics injected by every other AS, including a "economic policy" component. BGP is policy-based precisely because ASes do not trust each other's metrics, this has been understood since the 1990s.

The Zone Server kitchen sink (DNS + DHCP + NTP + OAuth + telemetry + ACL + NAT + WHOIS validation + PVRST root) concentrates a dozen unrelated functions into one box on one hardcoded address (.253/.254). This is an operational and security anti-pattern.

PVRST is mandated. PVRST is a Cisco-proprietary spanning tree variant, mandating a vendor-specific protocol in a Standards-Track draft is a non-starter for IETF.

The companion drafts (WHOIS8, NetLog8, Update8, WiFi8, Zone Server, RINE, routing protocols) are all by the same author, none have working-group review, and the core draft depends on all of them to function.

https://xkcd.com/927/

Isn't it 2 weeks late for April Fools'?

Yes, let's conflate routing and addressing while throwing out decades of IPv6 implementation and design. (/sarcasm)

There's also at least three ipv9s, only one of which was a joke https://en.wikipedia.org/wiki/List_of_IP_version_numbers