3 ms·

All that code using BSD sockets is rewritten by now to support v6, right? If so, that can't be the reason, cause v4 is still dominant. And btw, what I suggeste

All that code using BSD sockets is rewritten by now to support v6, right? If so, that can't be the reason, cause v4 is still dominant. And btw, what I suggested would actually work without userspace code changes until you want to start subdividing the /32s. Cause v4 addresses would've still been valid in v6.

kstrauser 2y ago
Where would you store the other 96 bits. In the body?
- frollogaston 2y ago
  Ipv6 packet format was needed either way, but only with the 32-bit address space at first (the other 92 bits set to 0). You simply tell your system to start using v6 instead, and everything else stays the same. No dual-stack. Next step would be upgrading all those parts like DNS, DHCP, etc to accept the 128-bit addrs, which again can be done in isolation. Then finally, ISPs or home routers can start handing out longer addresses like 1.1.1.1.2.
  - Dylan16807 2y ago
    There are two ways for me to interpret "simply tell your system to start using v6". If it means upgrading every program, then your plan works but it's the same as how things work today. You're telling people to do a thing, and they aren't bothering. The "simple" step isn't simple at all. If it doesn't mean upgrading every program, then your rollout fails on the last step. You start handing out longer addresses and legacy programs can't access them.
    - frollogaston 2y ago
      It's the second one. But legacy programs did get upgraded, so I don't see why they wouldn't under this other plan. If anything, it's easier because you're only making the address field bigger and it's not a separate case. Some routers struggled with 128-bit addrs due to memory, and could've gotten away with like 48 or 64 bits if they're using DHCP.
      - Dylan16807 2y ago
        Lots of legacy programs, and current programs, and other things that could have been upgraded did not get upgraded. Getting to the situation where you can just flick a switch is not a realistic dream. There's not enough motivation for the average business to add support for a version that isn't in use yet.

kstrauser 2y ago

Where would you store the other 96 bits. In the body?

frollogaston 2y ago
Ipv6 packet format was needed either way, but only with the 32-bit address space at first (the other 92 bits set to 0). You simply tell your system to start using v6 instead, and everything else stays the same. No dual-stack. Next step would be upgrading all those parts like DNS, DHCP, etc to accept the 128-bit addrs, which again can be done in isolation. Then finally, ISPs or home routers can start handing out longer addresses like 1.1.1.1.2.
- Dylan16807 2y ago
  There are two ways for me to interpret "simply tell your system to start using v6". If it means upgrading every program, then your plan works but it's the same as how things work today. You're telling people to do a thing, and they aren't bothering. The "simple" step isn't simple at all. If it doesn't mean upgrading every program, then your rollout fails on the last step. You start handing out longer addresses and legacy programs can't access them.
  - frollogaston 2y ago
    It's the second one. But legacy programs did get upgraded, so I don't see why they wouldn't under this other plan. If anything, it's easier because you're only making the address field bigger and it's not a separate case. Some routers struggled with 128-bit addrs due to memory, and could've gotten away with like 48 or 64 bits if they're using DHCP.
    - Dylan16807 2y ago
      Lots of legacy programs, and current programs, and other things that could have been upgraded did not get upgraded. Getting to the situation where you can just flick a switch is not a realistic dream. There's not enough motivation for the average business to add support for a version that isn't in use yet.