3 ms·

> You just support longer addresses, that's it. There is no "just" in this. Copy-pasting from my other comment: -- IPv4 data structures have four bytes/octe

> You just support longer addresses, that's it. There is no "just" in this. Copy-pasting from my other comment: -- IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+. And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere. But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection. -- So "just" expanding IPv4 to IPv4+ ends up being the exact same amount of work as ended up with IPv6. The only thing you could say with "just" more addresses is keeping ARP and the like (instead of DAD, etc).

hot_gril 3y ago
Building it is the same amount of work as building ipv6 support. Adopting it is not the same work as adopting v6. We already have ubiquitous v6 hardware/software support, but it's a whole 'nother thing to actually use it. 1. Add v4.1 support, but keep using 32-bit addresses. 2. Start using >32-bit addresses when ready. By the way, the WWW has gone through transitions like adopting HTTPS and banning old versions of TLS with it. Crucial to that was having transitional periods where both things work. This step was missed in ipv6 rollout.
- throw0101b 3y ago
  > 1. Add v4.1 support, but keep using 32-bit addresses. 2. Start using >32-bit addresses when ready. When who is ready? Different people/organizations will be ready at different times. Some people will not be able to get IPv4 addresses so will be 'stuck' with being IPv4.1-only. Given the finite IPv4 addresses, some will move the IPv4 addresses to revenue-generating areas and will go IPv4.1-only internally—which is what prompted Microsoft to be IPv6-only/first internally: their IPv4 addresses got sent to Azure: * https://www.arin.net/blog/2019/04/03/microsoft-works-toward-ipv6-only-single-stack-network/ https://www.arin.net/blog/2019/04/03/microsoft-works-toward-... And once that happens, which it would inevitably too with IPv4.1, we're at: If you have a IPv4-only network elements/devices, they cannot talk to IPv4.1-only devices/services (and vice verse), so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an IPv4.1 network is an island in a sea of IPv4, so you have to have tunneling. Of course some may have both IPv4 and IPv4.1, and want to talk to something has also has IPv4 and IPv4.1, so now you have to have code for source/destination selection.
  - hot_gril 3y ago
    Switch to >32-bit when enough routers/hosts support it, i.e. they can parse the new packet format. We've already accomplished that with v6 long ago. In the meantime, ISPs that cannot afford enough 32-bit addresses for their customers can hand out 40-bit ones and perform a NAT-like translation. Same as what they're doing now with cgnat, except there's an exit strategy.
    - throw0101b 3y ago
      > Switch to >32-bit when enough routers/hosts support it, i.e. they can parse the new packet format. We've already accomplished that with v6 long ago. And who gets to decide when "enough" devices support it? Who decides on that flag day? * https://en.wikipedia.org/wiki/Flag_day_(computing) https://en.wikipedia.org/wiki/Flag_day_(computing) The Tier 1s? * https://en.wikipedia.org/wiki/Tier_1_network https://en.wikipedia.org/wiki/Tier_1_network Good luck coördinating that with the global Internet.
      - hot_gril 3y ago
        Individual hosts decide. Same as how I can no longer visit httpS://chase.com on my ancient PC that doesn't support HTTPS, let alone a modern web renderer. Chase has left it behind. ISPs also decide; they turn off their cgnats and start handing out /48s etc, at the latest when the cost of leasing /32s addresses exceeds the cost of being incompatible with a tiny few straggling hosts.

hot_gril 3y ago

Building it is the same amount of work as building ipv6 support. Adopting it is not the same work as adopting v6. We already have ubiquitous v6 hardware/software support, but it's a whole 'nother thing to actually use it. 1. Add v4.1 support, but keep using 32-bit addresses. 2. Start using >32-bit addresses when ready. By the way, the WWW has gone through transitions like adopting HTTPS and banning old versions of TLS with it. Crucial to that was having transitional periods where both things work. This step was missed in ipv6 rollout.

throw0101b 3y ago
> 1. Add v4.1 support, but keep using 32-bit addresses. 2. Start using >32-bit addresses when ready. When who is ready? Different people/organizations will be ready at different times. Some people will not be able to get IPv4 addresses so will be 'stuck' with being IPv4.1-only. Given the finite IPv4 addresses, some will move the IPv4 addresses to revenue-generating areas and will go IPv4.1-only internally—which is what prompted Microsoft to be IPv6-only/first internally: their IPv4 addresses got sent to Azure: * https://www.arin.net/blog/2019/04/03/microsoft-works-toward-ipv6-only-single-stack-network/ https://www.arin.net/blog/2019/04/03/microsoft-works-toward-... And once that happens, which it would inevitably too with IPv4.1, we're at: If you have a IPv4-only network elements/devices, they cannot talk to IPv4.1-only devices/services (and vice verse), so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an IPv4.1 network is an island in a sea of IPv4, so you have to have tunneling. Of course some may have both IPv4 and IPv4.1, and want to talk to something has also has IPv4 and IPv4.1, so now you have to have code for source/destination selection.
- hot_gril 3y ago
  Switch to >32-bit when enough routers/hosts support it, i.e. they can parse the new packet format. We've already accomplished that with v6 long ago. In the meantime, ISPs that cannot afford enough 32-bit addresses for their customers can hand out 40-bit ones and perform a NAT-like translation. Same as what they're doing now with cgnat, except there's an exit strategy.
  - throw0101b 3y ago
    > Switch to >32-bit when enough routers/hosts support it, i.e. they can parse the new packet format. We've already accomplished that with v6 long ago. And who gets to decide when "enough" devices support it? Who decides on that flag day? * https://en.wikipedia.org/wiki/Flag_day_(computing) https://en.wikipedia.org/wiki/Flag_day_(computing) The Tier 1s? * https://en.wikipedia.org/wiki/Tier_1_network https://en.wikipedia.org/wiki/Tier_1_network Good luck coördinating that with the global Internet.
    - hot_gril 3y ago
      Individual hosts decide. Same as how I can no longer visit httpS://chase.com on my ancient PC that doesn't support HTTPS, let alone a modern web renderer. Chase has left it behind. ISPs also decide; they turn off their cgnats and start handing out /48s etc, at the latest when the cost of leasing /32s addresses exceeds the cost of being incompatible with a tiny few straggling hosts.