4 ms·

> Only the edge equipment would need to be IPv4+ aware. "Only"? That's still the networking stack of every desktop, laptop, phone, printer, room presentation d

> Only the edge equipment would need to be IPv4+ aware. "Only"? That's still the networking stack of every desktop, laptop, phone, printer, room presentation device, IoT thing-y. Also every firewall device. Then recompile every application to use the new data structures with more bits for addresses. And let's not forget you have to update all the DNS code because A records are hardcoded to 32-bits, so you need a new record type, and a mechanism to deal with getting both long and short addresses in the reply (e.g., Happy Eyeballs). Then how do you deal with a service that only has a "IPv4+" address but application code that is only IPv4-plain? Basically all the code and infrastructure that needed to be updated and deployed for IPv6 would have to be done for IPv4+.

almosthere 10mo ago
But the desktop/laptop/phone/printer was the EASIEST thing to change in that 30 year history. And it would have been the easiest thing to demand a change req from a company for.
- throw0101a 10mo ago
  Yes: but the process would have been exactly the same whether for a hypothetical IPv4+ or the IPng/IPv6 that was decided on; pushing new code to every last corner of the IP universe. How could it have been otherwise given the original network structures were all of fixed lengths of 32 bits?
  - frumplestlatz 10mo ago
    The new code would have been vastly simpler. IPv6 is second system syndrome personified. What we needed was the equivalent of ASCII->UTF8.
    - AmalgatedAmoeba 10mo ago
      As someone with non-ascii and non-latin-1 characters in my surname, I can tell you that the ascii->utf8 migration still hasn’t finished.
      - pas 10mo ago
        Just a few weeks ago I ordered something from JBL US and somehow on the UPS sticker an "Á" became a caret "^" shrug Most of the world is a circus.
    - Macha 10mo ago
      If you hand UTF-8 that actually uses anything added by utf-8 to something that can only render ASCII, the text will be garbled. People can read garbled text ok if it’s a few missing accented characters in a western language, but it’s no good for Japanese or Arabic. In networking terms, this is like a protocol which can reach ipv4 hosts only but loses packets to the ipv4+ hosts randomly depending on what it passes through. Who would adopt a networking technology that fails randomly?
    - throw0101a 10mo ago
      If we have IPv4 address 1.2.3.4, and the hypothetical IPv4+ adds 1.2.3.4.1.2.3.4 (or longer), how would a IPv4-only router handle 1.2.3.4.1.2.3.4? If an IPv4-only host or application gets a DNS response with 1.2.3.4.1.2.3.4, how is it supposed to use it? As I see it, the transition mechanism for some IPv4+ that 'only' has longer addresses is exactly the same as for IPv6: new code paths that use new data structures, with a gradual rollout with tech refreshes and code updates where hosts slowly go from IPv4-only to IPv4-and-IPv4+ at different rates in different organizations. If you think it's somehow different, can you explain how it is so? What proposal available (especially when IPng was being decided on in the 1990s) would have allowed for a transition that is different than the one described above (gradual, uncoördinated rollout)? * https://datatracker.ietf.org/doc/html/rfc1726 https://datatracker.ietf.org/doc/html/rfc1726 * https://datatracker.ietf.org/doc/html/rfc1752 https://datatracker.ietf.org/doc/html/rfc1752
      - avidiax 10mo ago
        The proposal is that IPv4+ would be interpretable as an IPv4 packet. Either the IP header is extended, or we add another protocol layer for the IPv4+ bits (IPv4+ is another envelope for the user payload). DNS is like today: A and AAAA records for IPv4 and IPv4+ respectively. Core routers do not need to know about IPv4+, and might never know. The transition is similar to 6to4. The edge router does translation to allow IPv4+ hosts to connect to IPv4 hosts. IPv4 hosts are unable to connect to IPv4+ directly (only via NAT). So it has the similar problem to IPv6 that you ideally want all servers to have a full IPv4 address. What you don't have is a completely parallel addressing system, requirements to upgrade all routers (only edge routers for 4+ networks), requirements to have your ISP cooperate (they can just give you an IPv4 and you handle IPv4+ with your own router), and no need that the clients have two stacks operating at once. It's essentially a better NAT, one where the clients behind other NATs can directly connect, and where the NAT gradually disappears completely.
wpm 10mo ago
And in 30 years, all of that has basically already happened and afoption is still absymal.
- Dagger2 10mo ago
  v6 has nearly 3 billion users. How is that abysmal? We've never done something like the v4->v6 migration before, on this sort of scale. It's not clear what the par time for something like this is. Maybe 30 years is a normal amount of time for it to take?
  - morshu9001 10mo ago
    HTTP->HTTPS was this kind of scale, and it was smooth because they changed as little as possible while also being very careful about default behaviors. 3 billion people sorta use ipv6, but not really, cause almost all of those also rely on ipv4 and no host can really go ipv6-only. Meanwhile, many sites are HTTPS-only.
    - Dagger2 10mo ago
      And because it's a layer 7 thing, so it only required updating the server and client software, not the OS... and only the client and server endpoints and not the routers in between... and because we only have two browser vendors who between them can push the ecosystem around, and maybe half a dozen relevant web server daemons. Layer 3 of the Internet is the one that requires support in all software and on all routers in the network path, and those are run by millions of people in hundreds of countries with no central entity that can force them to do anything. HTTP->HTTPS is only similar in terms of number of users, not in terms of the deployment itself. The network effects for IP are much stronger than for HTTP. They don't "sorta" use v6, they're properly using it, and you can certainly go v6-only. I'm posting from a machine with no v4. Also, if you want to go there: HTTPS was released before IPv6, and yet still no browser is HTTPS only, despite how much easier it is to deploy it.
      - morshu9001 10mo ago

almosthere 10mo ago

But the desktop/laptop/phone/printer was the EASIEST thing to change in that 30 year history. And it would have been the easiest thing to demand a change req from a company for.

throw0101a 10mo ago
Yes: but the process would have been exactly the same whether for a hypothetical IPv4+ or the IPng/IPv6 that was decided on; pushing new code to every last corner of the IP universe. How could it have been otherwise given the original network structures were all of fixed lengths of 32 bits?
- frumplestlatz 10mo ago
  The new code would have been vastly simpler. IPv6 is second system syndrome personified. What we needed was the equivalent of ASCII->UTF8.
  - AmalgatedAmoeba 10mo ago
    As someone with non-ascii and non-latin-1 characters in my surname, I can tell you that the ascii->utf8 migration still hasn’t finished.
    - pas 10mo ago
      Just a few weeks ago I ordered something from JBL US and somehow on the UPS sticker an "Á" became a caret "^" shrug Most of the world is a circus.
  - Macha 10mo ago
    If you hand UTF-8 that actually uses anything added by utf-8 to something that can only render ASCII, the text will be garbled. People can read garbled text ok if it’s a few missing accented characters in a western language, but it’s no good for Japanese or Arabic. In networking terms, this is like a protocol which can reach ipv4 hosts only but loses packets to the ipv4+ hosts randomly depending on what it passes through. Who would adopt a networking technology that fails randomly?
  - throw0101a 10mo ago
    If we have IPv4 address 1.2.3.4, and the hypothetical IPv4+ adds 1.2.3.4.1.2.3.4 (or longer), how would a IPv4-only router handle 1.2.3.4.1.2.3.4? If an IPv4-only host or application gets a DNS response with 1.2.3.4.1.2.3.4, how is it supposed to use it? As I see it, the transition mechanism for some IPv4+ that 'only' has longer addresses is exactly the same as for IPv6: new code paths that use new data structures, with a gradual rollout with tech refreshes and code updates where hosts slowly go from IPv4-only to IPv4-and-IPv4+ at different rates in different organizations. If you think it's somehow different, can you explain how it is so? What proposal available (especially when IPng was being decided on in the 1990s) would have allowed for a transition that is different than the one described above (gradual, uncoördinated rollout)? * https://datatracker.ietf.org/doc/html/rfc1726 https://datatracker.ietf.org/doc/html/rfc1726 * https://datatracker.ietf.org/doc/html/rfc1752 https://datatracker.ietf.org/doc/html/rfc1752
    - avidiax 10mo ago
      The proposal is that IPv4+ would be interpretable as an IPv4 packet. Either the IP header is extended, or we add another protocol layer for the IPv4+ bits (IPv4+ is another envelope for the user payload). DNS is like today: A and AAAA records for IPv4 and IPv4+ respectively. Core routers do not need to know about IPv4+, and might never know. The transition is similar to 6to4. The edge router does translation to allow IPv4+ hosts to connect to IPv4 hosts. IPv4 hosts are unable to connect to IPv4+ directly (only via NAT). So it has the similar problem to IPv6 that you ideally want all servers to have a full IPv4 address. What you don't have is a completely parallel addressing system, requirements to upgrade all routers (only edge routers for 4+ networks), requirements to have your ISP cooperate (they can just give you an IPv4 and you handle IPv4+ with your own router), and no need that the clients have two stacks operating at once. It's essentially a better NAT, one where the clients behind other NATs can directly connect, and where the NAT gradually disappears completely.

wpm 10mo ago

And in 30 years, all of that has basically already happened and afoption is still absymal.

Dagger2 10mo ago
v6 has nearly 3 billion users. How is that abysmal? We've never done something like the v4->v6 migration before, on this sort of scale. It's not clear what the par time for something like this is. Maybe 30 years is a normal amount of time for it to take?
- morshu9001 10mo ago
  HTTP->HTTPS was this kind of scale, and it was smooth because they changed as little as possible while also being very careful about default behaviors. 3 billion people sorta use ipv6, but not really, cause almost all of those also rely on ipv4 and no host can really go ipv6-only. Meanwhile, many sites are HTTPS-only.
  - Dagger2 10mo ago
    And because it's a layer 7 thing, so it only required updating the server and client software, not the OS... and only the client and server endpoints and not the routers in between... and because we only have two browser vendors who between them can push the ecosystem around, and maybe half a dozen relevant web server daemons. Layer 3 of the Internet is the one that requires support in all software and on all routers in the network path, and those are run by millions of people in hundreds of countries with no central entity that can force them to do anything. HTTP->HTTPS is only similar in terms of number of users, not in terms of the deployment itself. The network effects for IP are much stronger than for HTTP. They don't "sorta" use v6, they're properly using it, and you can certainly go v6-only. I'm posting from a machine with no v4. Also, if you want to go there: HTTPS was released before IPv6, and yet still no browser is HTTPS only, despite how much easier it is to deploy it.
    - morshu9001 10mo ago