4 ms·

Something like 1:2:3:4:a:b:c:d where the most significant 32bits are a valid IPv4. The kernel figures out and keep all others the same (NAT etc). We extend the

Something like 1:2:3:4:a:b:c:d where the most significant 32bits are a valid IPv4. The kernel figures out and keep all others the same (NAT etc). We extend the address space, not invent a new stack. The IPv6 critics shout out that this would be a viable solution.

Dagger2 6mo ago
Okay, so you've figured out how to make v4 addressable from v8. Good job. That lets v8 hosts address a v4 host via a v8 address. 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.
- tsoukase 6mo ago
  > How are you going to make v8 addressable from v4? 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.
  - lolc 6mo ago
    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 https://en.wikipedia.org/wiki/Dagen_H
    - tsoukase 6mo ago
      [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 6mo ago
        You haven't answered my question. When do I switch addresses in DNS?
        tsoukase 6mo ago
        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 6mo ago
        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 6mo ago
    So basically, instead of extending the v4 address space you're going to make a new stack and everybody needs to switch to it to be able to communicate with v8. That's the exact thing you said you weren't doing. > 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.

Dagger2 6mo ago

Okay, so you've figured out how to make v4 addressable from v8. Good job. That lets v8 hosts address a v4 host via a v8 address. 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.

tsoukase 6mo ago
> How are you going to make v8 addressable from v4? 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.
- lolc 6mo ago
  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 https://en.wikipedia.org/wiki/Dagen_H
  - tsoukase 6mo ago
    [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 6mo ago
      You haven't answered my question. When do I switch addresses in DNS?
      - tsoukase 6mo ago
        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 6mo ago
        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 6mo ago
  So basically, instead of extending the v4 address space you're going to make a new stack and everybody needs to switch to it to be able to communicate with v8. That's the exact thing you said you weren't doing. > 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.