3 ms·

> Just adding bits to the address isn't as simple as it seems. They said the same in Y2K, and turned out that people were able to extend their date fields and

by amelius 6mo ago

> Just adding bits to the address isn't as simple as it seems. They said the same in Y2K, and turned out that people were able to extend their date fields and the systems ran just fine.

Dylan16807 6mo ago
You can add bits to your own systems fine. When you want your packets to work on other people's routers, it stops being fine.
- amelius 6mo ago
  If that means those other people cannot reach the internet, then I'm sure those people will fix that faster than anything ever fixed before.
  - Dylan16807 6mo ago
    No, it means you can't reach the Internet. Or it means a ton of people can't connect to you because of your netcode preferences, and that makes your boss very upset. It'll get fixed extremely fast, and fixed means turning IPv4 back on.
  - tardedmeme 6mo ago
    that's literally the exact situation with ipv6
    - amelius 6mo ago
      Except those people just use ipv4 instead.
      - tardedmeme 6mo ago
        so your solution is "let's do exactly the same as ipv6 but change the number and also force people to use it"?
throw0101a 6mo ago
> They said the same in Y2K, and turned out that people were able to extend their date fields and the systems ran just fine. Ah yes, the old IPv4 with 'just' adding more address byte(s) idea ("IPv4+"): So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.) You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to: * update the IP stack (like with IPv6) * tell applications about new DNS records (like IPv6) * set up translation layers for legacy-only code to reach extended-only destination (like IPv6 with DNS64/NAT64, CLAT, etc) You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space. Deploying the new "IPv4+" code will take time, there will partial deployment of IPv4+ is no different than having partial deployment of IPv6: you have islands of it and have to fall back to the 'legacy' IPv4-plain protocol when the new protocol fails to connect: * https://en.wikipedia.org/wiki/Happy_Eyeballs https://en.wikipedia.org/wiki/Happy_Eyeballs (This idea of "just add more addresses" comes up in every discussion of IPv6, and people do not bother thinking about what needs to change to "just" do it.) Meanwhile, if you have a database it's fairly trivial to add a new field with a four-digit year, and since you're probably only using the data internally, so your co-ordination problem is generally with-in one organization. The co-ordination problem with a new Internet protocol is global.

by amelius 6mo ago

> Just adding bits to the address isn't as simple as it seems. They said the same in Y2K, and turned out that people were able to extend their date fields and the systems ran just fine.

Dylan16807 6mo ago

You can add bits to your own systems fine. When you want your packets to work on other people's routers, it stops being fine.

amelius 6mo ago
If that means those other people cannot reach the internet, then I'm sure those people will fix that faster than anything ever fixed before.
- Dylan16807 6mo ago
  No, it means you can't reach the Internet. Or it means a ton of people can't connect to you because of your netcode preferences, and that makes your boss very upset. It'll get fixed extremely fast, and fixed means turning IPv4 back on.
- tardedmeme 6mo ago
  that's literally the exact situation with ipv6
  - amelius 6mo ago
    Except those people just use ipv4 instead.
    - tardedmeme 6mo ago
      so your solution is "let's do exactly the same as ipv6 but change the number and also force people to use it"?

throw0101a 6mo ago

> They said the same in Y2K, and turned out that people were able to extend their date fields and the systems ran just fine. Ah yes, the old IPv4 with 'just' adding more address byte(s) idea ("IPv4+"): So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.) You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to: * update the IP stack (like with IPv6) * tell applications about new DNS records (like IPv6) * set up translation layers for legacy-only code to reach extended-only destination (like IPv6 with DNS64/NAT64, CLAT, etc) You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space. Deploying the new "IPv4+" code will take time, there will partial deployment of IPv4+ is no different than having partial deployment of IPv6: you have islands of it and have to fall back to the 'legacy' IPv4-plain protocol when the new protocol fails to connect: * https://en.wikipedia.org/wiki/Happy_Eyeballs https://en.wikipedia.org/wiki/Happy_Eyeballs (This idea of "just add more addresses" comes up in every discussion of IPv6, and people do not bother thinking about what needs to change to "just" do it.) Meanwhile, if you have a database it's fairly trivial to add a new field with a four-digit year, and since you're probably only using the data internally, so your co-ordination problem is generally with-in one organization. The co-ordination problem with a new Internet protocol is global.