3 ms·

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/softwar

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.

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.