It'll be objectively worse. IPv6 is at least sort of supported by a non-negligible number of devices, software and organizations. This IPv8 would be a whole new protocol, that no one out there supports. The fact that version 8 was already defined in [an obsolete] RFC1621 doesn't help either.
Even if you decide to try to make it a Frankenstein's monster of a protocol, making it a two IPv4 packets wrapped in each other to create a v4+v4=v8 address space, you'll need a whole new routing solution for the Internet, as those encapsulations would have issues with NATs. And that'll be way more error prone (and thus, less secure), because it'll be theoretically possible to accidentally mix up v4 and inner-half-of-v8 traffic.
Nah, if we can't get enough people to adopt IPv6, there's no chance we'll get even more people to adopt some other IPvX (unless something truly extraordinary happens that would trigger such adoption, of course).
Are you saying you believe it's truly impossible to create a new backwards compatible standard that expands the address space and doesn't require everyone to upgrade for it to work?
It isn't possible to make backwards compatible standard that expands the address space. Where are you going to put the extra address bits in the IPv4 header?
It also can't be backwards compatible with IPv4 networking and software. The network gear will drop extra address, the OS will ignore it, and software will blow up.
It would be much better to make a new version. But if going to make new protocol, might as well make the address big enough to not need expansion again.
Then you have to update every networking device to support the new standard. And update all the protocols (DHCP, etc) for more address space. That part is what took a lot of the time for IPv6. Then you have to update all of the software to support 64-bit addresses. Luckily, most of the work was already done for IPv6.
Then you have to support a transition mechanism to talk to IPv4. Except there isn't enough space in new address. IPv6 on the other hand, has enough address space to stuff the IPv4 host and port in the IPv6 address for stateless NAT.
> Where are you going to put the extra address bits in the IPv4 header?
The optional part. EIP proposed using 16 bits (minimum) to bump the address space to 40 bits (the EIP extension portion is variable-sized so it can go higher until you reach header option limits): https://archive.org/details/rfc1385/page/4/mode/2up
The effort is a bit smaller because existing stacks can already read what's in the EIP part as it disguises itself as an option header. The change is behavioral not structural.
Also with the extra octet added we'd get ~254 current-IPv4-sized clusters of addresses. If a unit inside one of these doesn't really care about the others they can skip supplying this information entirely, i.e. not all participants need to understand the extension. LANs, internal networks and residential use comes to mind as examples in which case only the gateway has to be updated just like the RFC says.
With IPv6 participation is all or nothing or dual stack, but then this is ~1.1 stack :)
That RFC glosses over a LOT of details. I'm skeptical the effort would be a bit smaller, once you consider what is required for routing and the "translation service." That's totally glossed over in the RFC, by the way.
Unless you're planning on doing all IP communications in user space (or within your network "cluster"), the OS and IP stack still needs to be updated, you need a new addressing format, applications need to be aware of it, etc. If you want to actually make use of the new address space, it all needs to be updated... just like IPv6.
No, sorry. Very few switches and not all routers do that in software. If all that is in an ASIC then that part just can't be added to the address without new hardware.
So no, good attempt but it's pretty much still a 'upgrade all the routers and switches' kind of issue just like IPv6.
I'm not going to say it's truly impossible, but it's practically just-about impossible.
There's no straightforward way of getting old hosts to be able to address anything in the new expanded space, or older routers to be able to route to it.
So you have to basically dual-stack it, and, oops, you've created the exact same situation with IPv6...
If it's possible, why has no one done it? Most of the backwards compatible "solutions" that are presented just run into the same issues as IPv6 but with a more quirky design.
Even if you decide to try to make it a Frankenstein's monster of a protocol, making it a two IPv4 packets wrapped in each other to create a v4+v4=v8 address space, you'll need a whole new routing solution for the Internet, as those encapsulations would have issues with NATs. And that'll be way more error prone (and thus, less secure), because it'll be theoretically possible to accidentally mix up v4 and inner-half-of-v8 traffic.
Nah, if we can't get enough people to adopt IPv6, there's no chance we'll get even more people to adopt some other IPvX (unless something truly extraordinary happens that would trigger such adoption, of course).