How are you going to make v8 addressable from v4? Because you need to do this too for communication to work.
Also, you've made v4 addressable from v8, and you're about to explain how you make v8 addressable from v4... but that's just addressing, i.e. identifying the right host. How are you going to actually send packets from v8 to v4, and also from v4 to v8?
> The IPv6 critics shout out that this would be a viable solution.
But they never bother to understand enough of the problem to contribute anything useful. Either they can't come up with something that works, or they come up with something that they didn't realize v6 already did.
I expected this question and have thought about it. Here is an idea: all nodes (PCs, routers etc) run an updated stack, which sends/receives 64bit addresses. If it receives 1:2:3:4:0:0:0:0, that's v4 and continues as such. It's on the ISP when the switch happens because they deliver the addresses. The user notices nothing. Edge cases can arise and be handled accordingly.
The update from 32-to-64 will be massively pushed to all kernels and userspaces in a short time so to shorten outages.
The idea that any ISP would do a Dagen H is very alien to how an ISP thinks. https://en.wikipedia.org/wiki/Dagen_H
There are two groups that should update to v8 in order to be fully functional: users' OS net stack and ISPs' infra.
The incompatibility of IPvs between two endpoints can be solved by a couple of mechanisms. One is to make a preflight check if all nodes support v8, another is to start with a flag isv8=1 and change it along the path. If a single node is still at v4, all the communication continues v4-like (the v8 nodes send 0 at the ls32b).
It will be a gradual migration, in some regions faster or slower, but it will be SEAMLESS for the user, without the awful v6 UX that we have now.
> There are two groups that should update to v8 in order to be fully functional: users' OS net stack and ISPs' infra.
A lot of software hardcodes AF_INET or sockaddr_in, and so can only handle 32-bit addresses. Also, there's the end-user's border router, and any internal routers on the client or server side, and the LANs on the client and server sides. There are databases, protocols and data structures that store IP addresses. Any attempt to use v8 with any of these will break them even if half of the v8 address is set to zeros, because they can't handle the 64 bits of a v8 address. They'll either reject the address or it'll corrupt the next 32 bits of memory. A seamless update to the OS net stack and ISP infra isn't sufficient to make them work with v8, because they'll still be limited to 32 bits.
I understand that your core idea is to say that a subset of the v8 address space maps directly to the v4 address space, so that you can convert that subset to v4 to work with the above things. This idea itself isn't bad; it's a perfectly sensible backwards compatibility mechanism that's used by v6 too. You're correct that it allows just that subset to be passed to an application over an AF_INET socket, used to send/receive v4 packets to the corresponding v4 address and so on. This approach is seamless if you stick to exposing the addresses as v4 addresses rather than as v8, because then they could be handled the same way v4 addresses are.
The problem is, you can only make it seamless by hiding the full v8 addresses and pretending they're v4, which can only be done for a small fraction of v8 addresses. What about the rest of them? You haven't actually extended v4's address space past 32 bits, so if you want to use v8's extra addresses you'll have to expose the full v8 addresses as v8 addresses, which is no longer seamless because that's a whole new stack the user and their software has to deal with.
If it was possible to seamlessly switch to bigger addresses, there would be no reason to restrict yourself to the subset of v8 addresses that end in :0:0:0:0 in the first place. You're doing that because using bigger addresses isn't seamless, which is an acknowledgement that a seamless upgrade to bigger addresses isn't possible. It would be if they were the same size, but then you've failed your goal of extending the address space.
So no, you can't claim this upgrade would be seamless unless you can remove the part that's only in there because it's not.
> If a single node is still at v4, all the communication continues v4-like (the v8 nodes send 0 at the ls32b).
If a single node is still at v4, that node will drop your v8 packets even if you set the ls32b to 0, because it doesn't understand the v8 packet format in the first place. This node will prevent you from switching to v8 even if you stick with the limited v4-compatible subset of v8 addresses.
> it will be SEAMLESS for the user, without the awful v6 UX that we have now
That "awful v6 UX" is the same UX you'd get with v8 if you tried to use the expanded address space. Or, if you limited yourself to just the v4-mapped subset of v6 then it would be just as seamless as v8 is. This should be obvious, because you already lived through OSs adding support for v6 in their net stacks and it was seamless so long as you stuck to the part of v6 which maps directly to v4. Which is what you were asking for, wasn't it?
> If it receives 1:2:3:4:0:0:0:0, that's v4 and continues as such
1:2:3:4:0:0:0:0 isn't v4, so it can't "continue as v4"... perhaps you meant that a router somewhere converts the packet to a v4 packet, but this is still only the v8->v4 direction. How do you map v8 into v4 so that the destination can reply?
> The update from 32-to-64 will be massively pushed to all kernels and userspaces in a short time so to shorten outages.
Right, add support for the new stack everywhere like we did with v6's 32-to-128 update. But just saying that it'll be done in a short time doesn't mean it will be.
