When can we expect IPv8 support in ROS? 
Ten years after it enters Internet Standards track.
That document is under heavy changes: https://datatracker.ietf.org/doc/draft-thain-ipv8/history/
It's hard to answer "when IPv8 in ROS" before we get answer to "when would that document be finished to be a base for IPv8 discussion?". Then we have to now "when could it be accepted as standard?"
The paper released just 4 days ago. @Guscht, this is he cutting edge technology. Thanks for posting it!
The interesting parts:
IPv4 is a proper subset of IPv8. An IPv8 address with the routing prefix field set to zero is an IPv4 address. No existing device, application, or network requires modification. The suite is 100% backward compatible. There is no flag day and no forced migration at any layer.
IPv8 also resolves IPv4 address exhaustion. Each Autonomous System Number (ASN) holder receives 4,294,967,296 host addresses. The global routing table is structurally bounded at one entry per ASN.
...
After 25 years of deployment effort IPv6 carries a minority of global internet traffic. The operational cost of the dual-stack transition model, combined with the absence of management improvement, proved commercially unacceptable.
...
A device connecting to an IPv8 network sends one DHCP8 Discover and receives one response containing every service endpoint it requires. No subsequent manual configuration is needed for any service. The device is fully operational -- authenticated, logged, time-synchronised, zone-policy-enforced -- before its first user interaction.
A protocol (v6) that has failed to gain broad acceptance in more than 20 years must be seen as a failure - theres no sugar-coating it. Its interesting to see that I am not the only one who thinks that.
Hopefully never. This whole idea looks like a joke made with AI. If someone hasnât adopted IPv6 in the past 20+ years, the reason is probably that they didnât need it. Why would they bother with IPv8?
I canât understand why IETF published this at all as well as I donât know what problem author want to resolve using IPv8.
Also if you waste your time to read this youâll find there will be no dual-stack, automagic backward IPv4 compability, routing limited to 1 entry per ASN to prevent BGP table grow, strong integration with DNS8/DCHP8, traffic filtering using DNS lookup and oAuth2 as authorization mechanism. This all looks like complete Internet refactor but in fact is a joke.
Published: 14 April 2026
It seems it somehow got delayed by 2 weeksâŠ
Interesting that the following papers referenced in the draft RFC are not available:
"Regional Inter-Network Exchange"
https://datatracker.ietf.org/doc/html/draft-thain-rine-00.
"IPv8 Routing Protocols", Work in Progress
https://datatracker.ietf.org/doc/html/draft-thain-routing-protocols-00.
"IPv8 Support Protocols -- ARP8, ICMPv8, and Route8"
https://datatracker.ietf.org/doc/html/draft-thain-support8-00.
"Update8 and NIC Certification"
https://datatracker.ietf.org/doc/html/draft-thain-update8-00.
"IPv8 Zone Server Architecture"
https://datatracker.ietf.org/doc/html/draft-thain-zoneserver-00.
...and users in the regions with the heaviest Internet censorship show the greatest interest in IPv8 protocol according to google trends.
ipv6 was too revolutionary and not backward compatible. Dual stack is almost a requirement, because so many things won't work with ipv6 only.
I'm old enough to remember when the ISO starndards based OSI protocol was going to be the replacement for all the proprietary networks, but by the time it was ready, IPv4 had already become the defacto standard.
This is an interesting talk from the June 2022 SouthEast LinuxFest. Why IPv6 Will Never Be Adopted
I think this slide is a good summary:
NAT routers and CGNAT are "good enough" for many people and was more of an "evolutionary" modification that was largely backward compatible. Similar to the 80/20 rule, and why being technically the best doesn't correlate to being most used. There are many examples.
There is a web page:
https://ipv8.es/en/
Yes, the IPv6 design had a lot of mistakes. Things like SLAAC and the whole idea of using 64 bits for a local address, the fact that there was no backward compatibility at all, no work at all was done at preparing ISPs for a transition, etc.
But by now the situation has stabilized and only backward ISPs do not support IPv6. There is no reason not to have dual-stack on the most common devices (computers, tablets, phones, settop boxes, etc).
What IPv6 needs is a âkiller applicationâ, something like a new social media network that only works on IPv6 and that makes the users demand IPv6 on their connection. Once that is available, the transition will be quick.
Unfortunately, that would likely be a peer-to-peer model that after some initial popularity is now being phased out in most places: everything that potentially could be peer-to-peer (or even has been) is being remodeled to be client-server again. Likely motivated by censorship-happy governments.
They already have a team of British developers working on it.
imagine for use theses 3 stacks in the future (10y maybe).
/ip for v4 rules/addr/settings
/ipv6 for v6 rules/addr/settings
/ipv8 for v8 rules/addr/settings
The time needed for setup rules will be complicated
ipv8 a non-serious, speculative project.
While IPv6 adoption has been slow, it remains the officially adopted successor to IPv4. IPv4 itself continues to "live on" through NAT (Network Address Translation) and other techniques, suggesting that a move to a hypothetical IPv8 is unnecessary.
tbh
how many "smart" light bulbs, garden irrigation system, and similar older "smart" home device will
- put stronger CPU
- add more RAM
only to run IPv6 ?
from this point of view, V8 draft has advantage that end user devices could stay at V4 without problem
OK. I didn't read the page too closely, so I might have missed something, but this looks like a case of the great [ipv8] being the enemy of the good [ipv6]. If ipv8 had come first, no one might have looked at ipv6. As it is, with a 'mere' 45.2 % of global traffic being ipv6, there is actually a lot of commitment to ipv6.
As I see it, it is far too late. There is a really substantial commitment to making ipv4 creak along with CGNAT. This proposal does not seem to offer backward compatibility for CGNAT extensions. The IP range 100.64.0.0/10 has been replicated unnumbered times, along with uncounted mis-configurations of CGNAT into 10.0.0.0/8 and I doubt there is any sane way of reconfiguring these into ipv8 and maintaining any form of backward compatibility.
As for ipv6, it was decided that everyone would get at least a /64 prefix delegation [apart from those ISPs who misconfigure by giving a /128 address and to some estent replicate the failings of ipv4 on their customers]. It always struck me as odd that customer subnetting would be dealt with by delegating a /56 or a /48, thereby depleting ISP space rather than customer space. It appears to be more sensible to me for the customer to be delegated a /64 and to do their subnetting within the /64. But overall, it is probably not a big issue, as long as end users don't encroach above /32 [leaving that for ISP networks] and as long as ISPs don't encroach below /96 [leaving that for end user networks]
And it is here, in subnetting, that the proposal fails for me. Neither this link nor the original paper seem to address end user subnetting, nor do they seem to leave space for it. We are where we are. IPv6 has a lot of traction, even if it has not overtaken IPv4 at the moment. We have passed the point where ipv4 backward compatibility is meaningfully achievable because ipv4 is already too broken.
The worst of all possible worlds I think would be to have ipv8 mixed in with ipv6 and ipv4 - essentially leading to triple stack implementations. A prerequisite for me of pv8 implementation would be an isotropic internet of only IPv4 or only ipv6. It is not practical to go back to only ipv4 and if we go to totally ipv6, then the Unique Selling Point of ipv8, disappears, because there would be no IPv4 to have backward compatibility with.
Yes, but there is SLAAC that prohibits subnetting a /64. It is one of the big mistakes in IPv6, it just doesnât make sense to have 64 bits for a local address and it even caused problems because the designers thought âhey you could use your MAC address as the local addressâ and forgot that made you trackable across networks, and had to be worked around with âprivacy extensionsâ idiocy.
So no, you cannot subnet a /64 and that means a consumer at an ISP should get a larger network. Sure a /56 would be more than enough and a /60 would probably be âenough for everybodyâ (similar to 640K RAM), but no the official recommendation is to give everyone a /48. So that is what we get here on consumer connections at ISPs⊠A true waste of space, but âit doesnât matterâ because the 128 bit address was much too long anyway. 64 bits with variable subnetting would have been more than enough.
I agree. There is too much invested in ipv6 for it to be abandoned. And having another new standard won't help at this time.
xkcd how standards proliferate
We will just have both ipv6 and ipv4 for a very long time.
Going through the IPv8 âdraftâ, it 100% reads like an LLM fever dream. This chestnut for instance is pretty golden in terms of slop:
>Every manageable element in an IPv8 network is authorised via OAuth2 JWT tokens served from a local cache. Every service a device requires is delivered in a single DHCP8 lease response. Every packet transiting to the internet is validated at egress against a DNS8 lookup and a WHOIS8 registered active route.
This is a good head scratcher too:
>PVRST is mandatory for all IPv8 L2 and L3 devices. MST is not recommended. Zone Servers are PVRST roots by default:
Like⊠hwat?
I was confused by this, until I remembered that anyone, even non-members can submit a âdraftâ. Meaning IPv8 is pretty clearly an either a late April Fools joke, or some moron attempting to make a name for themself.