[lolc]

At what point could I confidently publish the addresses 1:2:3:4:0:0:0:1 and 1:2:3:4:0:0:0:2 in DNS records for people to reach those two servers? After my ISP has switched, or after everybody's ISP has switched?

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

[tsoukase]

[The answer goes to both commenters]

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.

[lolc]

You haven't answered my question. When do I switch addresses in DNS?

[tsoukase]

The answer comes from the suggested design: you update your DNS right after you run the new stack, irrespective of what others (ISPs and users) do. The records will initially still function as v4 (discard the lb32b). Only when all others switch, they will enable their full length.

Obviously there should be simulations and refining to avoid edge cases and conflicts. I will not design the full spec.

[Dagger2]

So anybody without the new stack loses access to your site, because they're querying for the A record that you removed. How is this "a gradual migration" or "expanding the address space without inventing a new stack"?

Nobody will want to switch to the new stack if it means instantly losing clients that don't have the new stack yet, so the only way to switch would be to coordinate everybody on the planet to switch simultaneously. This is as far away from a gradual deployment as you can get. A flag day for the Internet isn't viable, no matter how much you shout it.

These are not edge case questions we're asking here. They're fundamental questions about how to expand the v4 address size without ultimately doing the same things v6 had to do. You don't need to design the full spec, but you don't get to argue we should replace v6 if the best alternative approach you can come up with works the same way v6 does and has the same limitations v6 does.

[Dagger2]

So you haven't solved the incompatibility at all. Your v8 requires the client, server and everything between them to support v8 or it has to fall back to using v4, just like v6 does.

> 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?