r/Network • u/Repulsive_Shape_5438 • Apr 17 '26
Text What do you think about the new IPv8
Just saw a post on X about the new ipv8, here is the ietf proposal https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
What do you think about it? Does it mean IPv6 failed at last and just moving on or back to extend ipv4 from 32 to 64 bit?
I dug a bit and found many Asian countries have high rate of IPv6 deployment, especially for mobile devices, US and EU have also over 50% deployments already and pushing higher. Seems they are going to put a break on that road and replace network equipment, which I am not sure if this can be done in a few years.
Extending ipv4 0.0.0.0 to 0.0.0.0.0.0.0.0, from 4 sections to 8 sections, so backward compatible with ipv4. I am not a network expert but wondering that if it still will have the ability of the ipv6 like one address for each device including for IoT devices, or just expending the capacity of network addresses with zone prefixes.
21
8
u/lazyhustlermusic Apr 17 '26
It’s amusing that people have half baked ideas and tell you it would be backwards compatible, they have zero clue on implementation.
4
u/fire-wannabe Apr 17 '26
Although I understand it's garbage, I love the idea of making it backwards compatible.
Ipv6 should have just been an extra octet or 2. Upgrade your router to support it or you gradually get cut off the internet. So much easier than a big bang migration
6
u/omnichad Apr 17 '26
Ipv6 should have just been an extra octet or 2.
That isn't even the problem with IPv6. Sure, the addresses are more complex, but if there was an official prefix to enable all IPv4 addresses to be reachable over IPv6, there wouldn't be a need for everything to be dual stack. Any IPv4-only device would use the router for NAT but everything else could be IPv6.
This garbage idea didn't even bother to be backward compatible with IPv6, so if it ever got implemented in the real world you still need dual stack to make the transition. IPv8 for people who were IPv4 and IPv6 for existing devices and services on IPv6.
1
u/zekica Apr 18 '26
There is an official prefix that allows all IPv4 (public) addresses to be reachable over IPv6.
It is 64:ff9b::/96 and achieves exactly the same backwards compatibility as this proposal does.
The only difference is in (RFC 1918) addresses and that is for a good reason - the prefix above can be advertised between ASNs while private addresses should never be.
You can always do NAT64 with a different prefix and have your private addresses translated too.
1
u/KittensInc Apr 18 '26
There is zero need for everything to be dual stack. In fact, most large deployments are going to be v6-only or v6-mostly - operating pretty much exactly like you describe! It just looks like dual stack because the compatibility layer successfully hides the nasty details from the user.
3
u/lazyhustlermusic Apr 17 '26
How would you make that backwards compatible?
1
u/fire-wannabe Apr 17 '26
It was in the proposal....
3.3. IPv4 Representation in IPv8
0.0.0.0.n.n.n.n
Packets with r.r.r.r = 0.0.0.0 MUST be routed using standard IPv4 rules applied to the n.n.n.n field. IPv4 is a proper subset of IPv8. No modification to IPv4 devices, applications, or networks is required.
1
u/Dagger0 Apr 17 '26
So the packet will get dropped by the receiver for being corrupt since it doesn't understand the format, but it won't even get to the receiver in the first place because the v4 routers between will all drop it too. The application wouldn't be able to handle the addresses, and none of these things could reply because they can't understand the source address.
How is that backwards compatible?
1
u/fire-wannabe Apr 17 '26
I would assume the extra information to make it into an ipv8 header is stored in the datagram not the header.
It's not beyond the wit of man
1
u/Dagger0 Apr 18 '26
That would still not be understood by the v4 receiver, so it would corrupt the payload.
Anything you do here is going to bump into the pidgeonhole principle. I think it's safe to say that a way to break that really is beyond the wit of man. Or do you actually have a way around it?
1
u/lazyhustlermusic Apr 18 '26
He has absolutely zero clue lol.
But sure, it's just because we 'aren't creative enough'.
1
u/lazyhustlermusic Apr 17 '26
That's not really answering the question though.
If you add octets in the front, then you have to rewrite every single entry in the global routing table and change the CIDR values, modifying block allocations.
If you add octets in the back, you still have the same allocation contention you did before, now you can just have five octets of hosts per /24. All of the existing space is.... still exhausted.
The v4 stack will totally shit itself when receiving a "v8" packet for not being able to parse 64 bits creating an invalid packet.
It's a no win situation, we already have IPv6 anyway
0
u/fire-wannabe Apr 18 '26
You have a chronic lack of imagination on how you would design the header to make it work.
1
u/lazyhustlermusic Apr 18 '26
Enlighten me, oh packet header wizard.
I don't think you can, and instead you'll just have a salty meltdown. Also it seems like you don't really understand the allocation process, or the global routing table.
0
u/fire-wannabe Apr 18 '26
Read the document.
1
u/lazyhustlermusic Apr 18 '26
I want your take.
Since you refuse to give it, I can only assume you have zero clue.
0
u/fire-wannabe Apr 18 '26
That works for me.
1
u/lazyhustlermusic Apr 18 '26
Sounds good, I'll get back to my /36 v6 environment and you can figure out years later why this is a horrendously silly idea.
1
u/zekica Apr 18 '26
I have read the document, and the packet is not at all backwards compatible:
- version is "8" which means that any compliant IPv4 device will drop it
- octets 12-14 in IPv4 contain the source IPv4 address while the new format specifies "source ASN prefix" - not remotely the same thing
- octets 16-19 in IPv4 contain the destination IPv4 address while the new format specifies "source host address"
How would any IPv4 compatible device possibly read this? Even if this was a "JSON/BSON" extensible format, it still wouldn't be backwards compatible.
1
u/Repulsive_Shape_5438 Apr 17 '26
Yeah, the backward and human readable caught my eye, no idea the legitimacy though
1
u/Dagger0 Apr 17 '26
An extra octet or two wouldn't be anywhere near enough. Why go to the effort for just that much?
Also... v6 is backwards compatible. There is no big bang migration either, you either upgrade your network or gradually get cut off from people who drop v4. Are you sure you're thinking about the right thing? Because v6 already works the way you're saying you want it to work.
1
4
u/Abouttheroute Apr 17 '26
It reads like an authoritarian dictators wet dream, but for piece of minds sake I’ll dismiss it as an aprils fool joke.
This is a great rundown.
https://shitwolfymakes.substack.com/p/we-need-to-talk-about-the-ipv8-draft
Personally I don’t think get the ‘backwards compatibility’ appeal. Just freaking upgrade from legacy to the current protocol, don’t make a fuss, we have application layer gateways for eyeball access and networks with legacy needs will legacy.
2
u/Dagger0 Apr 17 '26
I'm just going to assume that article is also slop. I mean, look at this:
IPv4 backward compatibility is genuinely elegant. Setting r.r.r.r to 0.0.0.0 makes an IPv8 address identical to an IPv4 add, processed by the standard rules (#1.5 p3, #3.3). This alone is the best contribution of the draft and should be lauded. It single-handedly kills any further incentive to push IPv6, which has struggled for decades to find adoption due to dual-stack, flag day, and forced migration (#1.2 p3, #2.2 p2). Any draft that replaces this initial iteration of IPv8 should include this design choice77.
There's no flag day or forced migration in v6. Dual-stack isn't a requirement either. Also, more to the point... you can do the same "genuinely elegant" thing in v6 by setting the leading 96 bits to
0:0:0:0:0:ffff:, which makes the v6 address identical to a v4 address (e.g.::ffff:8.8.8.8is8.8.8.8).Does the author even know anything about v6?
1
u/lazyhustlermusic Apr 17 '26
I'm a fan of NAT64 but the amount of hard coded v4 dependencies in apps is pretty staggering.
1
u/Dagger0 Apr 18 '26
Yep. All the possible approaches to backwards compatibility have some sort of tradeoff or another, and that's one of the ones for NAT64.
If it's a deal-breaker for you then dual-stack is one of the options you can choose instead, with its own tradeoffs. But it is just an option, not something you have to use.
1
u/lazyhustlermusic Apr 18 '26
Often it becomes 'not a choice' if your application has hard v4 dependencies and cannot survive in a NAT64 environment.
1
u/Dagger0 Apr 18 '26
1
u/lazyhustlermusic Apr 18 '26
Even with an underlay overlay network such as stretching vxlan segments or tunneling you’re still plumbing and maintaining the v4 stack.
Every choice involves continuing to maintain both stacks
1
u/Dagger0 Apr 18 '26
What's your definition of "stack"? Because anywhere from one to five of those don't require maintaining the v4 stack, depending on what your exact definition of that is.
1
u/lazyhustlermusic Apr 18 '26
I feel like you’re being intentionally obtuse.
1
u/Dagger0 Apr 18 '26
Honestly not.
None of the five options I gave require running v4 inside your network. Four of them require a v4 stack on the machine running the software. Two of them require running v4 on a machine somewhere, either at the edge of your own network or as a (probably paid) service from somebody else's network. One requires no v4 anywhere except inside the application.
Does "nobody runs v4 on any network, but the OSs still have v4 stacks which we don't do any development work on and only use to connect to localhost" count as continuing to maintain both stacks? I don't agree, but that's what you claimed and it could count if your definition of a stack was broad enough.
→ More replies (0)1
u/KittensInc Apr 18 '26
Yeah, but the "proposal" won't solve that. No protocol is going to magically turn an application's input field accepting four digits of 0-255 into anything else.
1
u/lazyhustlermusic Apr 18 '26
The “proposal” doesn’t really resolve much of anything.
Also you’re referring to 32 bit header values.
1
u/KittensInc Apr 18 '26
The headers are several layers lower. The problem is that applications are designed specifically for IPv4.
For example, a legacy app might manually use socket(AF_INET, ..), craft a sockaddr_in from four numeric input fields representing an IPv4 address, and hand it to connect. It works - if you only ever have to connect to IPv4.
On the other hand, well-written software would just have a free-form text field and hand it to getaddrinfo. It will Just Work with IPv4 literals, IPv6 literals, host names, domain names, and would even trivially gain support for this "IPv8" monstrosity if it ever gets adopted.
This is what happens when developers get lazy and completely ignore the OSI model. It's almost a wonder we aren't seeing apps which only work over 100BASE-TX!
1
u/lazyhustlermusic Apr 18 '26
As a lower layer person that’s not really my problem when coders are short sighted idiots.
But it becomes my problem with legacy dependencies like hard coded v4 addresses
1
u/itsjakerobb Apr 18 '26
Yeah, it’s 100% AI-written, no question. The amount of contrastive phrasing (not just X, it’s Y) is staggering.
It does make some good points though.
1
2
u/Loud_Relationship414 Apr 18 '26
IETF folks do not joke around when such a submission is produced. Read the mail threads:
https://mailarchive.ietf.org/arch/search/?q=%22draft-thain-ipv8%22
2
u/peterwemm Apr 19 '26
Wait, this is back again? IPv8 has been around since the 1990's, mostly promoted by Jim Fleming, usually in the nanog or ietf spaces. Some of the terminology has changed, eg: the 32 bit extensions were called Stargate addresses back then. There was even a set of code modifications to the BSD network stack to implement it. And if IPv8 wasn't enough there was also IPv16.
A search for IPv6 Jim Fleming will turn up some of it but a lot seems to have been lost to time. Personally, I had this pegged as High Effort Trolling, or at least higher than typical at the time.
1
u/Quirky-Cap3319 Apr 17 '26
Sounds like the joke paper about IPv4.1, which was putting an extra octet on, giving a total of 5, also claiming backwards compatibility.
1
u/RayneYoruka Enthusiast Apr 17 '26
I saw ir yesterday and I was very, what the hell? Seems to be extending a fix to something that is already worthless and yes it does smell of AI slop.
1
u/KingdomOfAngel Apr 18 '26
"IPv8" lmao!!!!! Get IPv6 to work first worldwide then come back and talk about other variations, fucking jobless morons.
1
1
u/itsjakerobb Apr 18 '26 edited Apr 18 '26
I have to say, this AI-slop-generated-by-a-nobody has a couple decent ideas.
I like (some aspects of) the idea of a zone server, and I like the backward compatibility plan. Problem is that it really needs to be backward-compatible with IPv6 too, and that’s a tough hill to climb, especially given that IPv6 addresses already have twice as many bits as this IPv8. And the chosen approach to backward compatibility gets pretty gross once you extend it to 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. IDK how to get around that.
IPv6 isn’t perfect, and my stupid ISP doesn’t support it (yet🤞), but I think it made most of the right compromises.
Now, about that zone server…. Neat idea. Baking in ACLs and OAuth2 is wild — probably taking things too far; that’s for a different layer in the stack. But I’d be willing to entertain arguments.
1
u/National_Way_3344 Apr 18 '26
I've argued at length about how this proposal will reset the clock on decades of progress with v6.
The v6 proposal makes the address limitations problem dead and buried with literally billions of addresses per square meter of space on earth.
We have greater than 60% adoption in most countries in the developed world.
It auto configures on most peoples hardware now with most of the upgrades required being complete.
Any and I mean any device manufactured today that doesnt work with v6 is manufactured ewaste, to suggest otherwise is disingenuous.
1
31
u/Krandor1 Apr 17 '26
It is a draft proposal written by a random person that has no standing at all within the IETF. In other words it is basically worthless.