Just fyi IPv8 was written by LLM with full on hallucinated citations and references. It isn’t being taken seriously by anyone.

It didn’t even make sense. It relies on DNS for nat and the like. Deranged networking plans from the non-mind of an LLM.

I recommend taking the time to learn IPv6 properly. It’s actually quite elegant and brings back the peer to peer, endpoint to endpoint connection ability of the old internet.

That's not how header backward compatibility works. IPv4 routers would discard the packet, not prepend zeroes.

Networking researcher here chiming in.

All IPv4 addresses can already be represented in the IPv6 address space, by the same method you describe here.

As for "backwards compatible with IPv4", I'm afraid that's not possible for the same reason IPv6 isn't getting major traction. Right now, we literally CANNOT upgrade our entire networking infrastructure. What you're proposing requires updating every switch and middlebox to support routing using additional bytes, which is physically impossible. The biggest problem would be middleboxes, which includes NAT router, firewalls, etc. For context: most middleboxes drop anything that is not IPv4/TCP or IPv4/UDP. This is why QUIC is encapsulated inside a UDP header (and funny enough, these vendors STILL didn't learn, trying to match a "QUIC header" despite Google themselves saying there is no fixed QUIC header), and RoCEv2 using a header that looks like UDP. There is absolutely no way a new L3 protocol that is not IPv4 (and in some cases, IPv6) can be supported by these boxes.

The only time we successfully replaced the L3 protocol was with the adaption of IPv4. In which networks were much smaller, and networking research was under the US DoD. The DoD basically gave an ultimatum that "if you don't switch to IP by this date we will cut your funding". That won't fly now that the Internet is managed by a cluster of ISPs.

Also: IPv6 is stupid simple. It's basically IPv4, with everything not commonly used stripped out (and added back with "optional headers", and a much larger address field. Since the address field is much larger, it is recommended to write them in hexadecimal, which looks more scary than IPv4.

Side note: I don't think any of these IP protocols is the solution here. If you only keep extending the address field, you're still gonna run into IP problems (routing, ddos, caching). The future of the Internet should be something like NDN. But for the same reason I described above, I don't think that's going to happen unless the Internet is a pile of smoldering ruins.

I saw the RFC for IPv8 recently

nitpick, but I would say "an RFC", as there's been a number of these over the years

you've gotten a couple responses so far, but I think the central issue is that "complexity" isn't the problem with IPv6 (and one could certainly argue that IPv6 is actually simpler)--the problem is compatibility. This article lays out the issue very well, and also links to this article (which is a more specific look at the IPv8 proposal you refer to). Both point to the same conclusion, which is that fundamentally--on first principles--existing hardware does not know how to handle the upgrade, which will require some sort of dual-stacking, which is the issue IPv6 currently has. (Not its technical merit.)

Note while you have cosmetic similarities to ipv4 addresses, the actual challenging part of that is the packet format and various translations.

We actually have a number of existing schemes for ipv4 mapping onto larger address space and the attendant NAT requirements. The presentation of addresses in an ipv4 looking way is the least of the challenges.

So don't take IPv8 seriously, it is slop and even in theory it wouldn't add anything new except a different cosmetic look to raw addresses and shortening the address space for no good reason.