3 ms·

So under this IPv4x proposal one gets an IPv4 /24, and receives a whole bunch of extended address space 'for free'. But right now you can get an IPv4 /24 (as y

So under this IPv4x proposal one gets an IPv4 /24, and receives a whole bunch of extended address space 'for free'. But right now you can get an IPv4 /24 (as you say), but you can get an IPv6 allocation 'for free' as we speak. In both cases 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 IPv4x 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.

zadikian 7mo ago
The point of IPv4x and similar proposals is to avoid a dual-stack scenario by reducing the risk of switching. Going from v4 to v4x doesn't mean changing all your routes and addresses (and possibly blacklists), you just enable it and everything still works. Network components can get updated/replaced with the longer addr field behind the scenes without user impact, then once the world is ready, ISPs can finally start using the extra address space.
- Dagger2 7mo ago
  But like the similar proposals, it fails to avoid a dual-stack scenario. Note that going from v4 to v6 also doesn't mean changing all your routes and addresses; you just enable it and everything still works. Network components can get updated behind the scenes without user impact. There's no flag day though; ISPs can start using the new address space as soon as they want, rather than being forced to wait until everybody else is ready.
  - zadikian 7mo ago
    You do have to change everything to actually use v6 rather than having v4 on the side. Re: flag day, I guess you could use the new address space of v4x before everyone is ready, provided the other side supports it.
    - throw0101d 7mo ago
      Having partial deployment of IPv4x 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 Getting "free" new-protocol addresses is also nothing new: > For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16. > For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets. * https://en.wikipedia.org/wiki/6to4 https://en.wikipedia.org/wiki/6to4 Translation boxes and tunnels are still needed for both IPv4x and IPv6.
      - zadikian 7mo ago
        Ok, I see what you mean then by 6to4 already supporting what v4x proposed, but that path wasn't taken either. It's a special feature with rare usage rather than the minimum default way of doing v6.
        Dagger2 7mo ago
        We did take that path. If you zoom in on the start of https://www.google.co.uk/intl/en/ipv6/statistics.html https://www.google.co.uk/intl/en/ipv6/statistics.html you can see that 6to4+Teredo was more common than native until 2010. (Okay, that's combined with Teredo, but I think probably 6to4 is the majority of it because Windows will use 6to4 without needing a registry change or custom application behavior.) You see it as a special feature with rare usage because it competed with native and lost. People overwhelmingly preferred deploying v6 natively instead of deploying 6to4. Obviously more people would be using it if it was the only option, but if you're trying to come up with an alternative to the way v6 went then "an approach that v6 took but which nobody wanted to use when native v6 was the alternative" might not be a very promising place to start.
        7mo ago

zadikian 7mo ago

The point of IPv4x and similar proposals is to avoid a dual-stack scenario by reducing the risk of switching. Going from v4 to v4x doesn't mean changing all your routes and addresses (and possibly blacklists), you just enable it and everything still works. Network components can get updated/replaced with the longer addr field behind the scenes without user impact, then once the world is ready, ISPs can finally start using the extra address space.

Dagger2 7mo ago
But like the similar proposals, it fails to avoid a dual-stack scenario. Note that going from v4 to v6 also doesn't mean changing all your routes and addresses; you just enable it and everything still works. Network components can get updated behind the scenes without user impact. There's no flag day though; ISPs can start using the new address space as soon as they want, rather than being forced to wait until everybody else is ready.
- zadikian 7mo ago
  You do have to change everything to actually use v6 rather than having v4 on the side. Re: flag day, I guess you could use the new address space of v4x before everyone is ready, provided the other side supports it.
  - throw0101d 7mo ago
    Having partial deployment of IPv4x 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 Getting "free" new-protocol addresses is also nothing new: > For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16. > For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets. * https://en.wikipedia.org/wiki/6to4 https://en.wikipedia.org/wiki/6to4 Translation boxes and tunnels are still needed for both IPv4x and IPv6.
    - zadikian 7mo ago
      Ok, I see what you mean then by 6to4 already supporting what v4x proposed, but that path wasn't taken either. It's a special feature with rare usage rather than the minimum default way of doing v6.
      - Dagger2 7mo ago
        We did take that path. If you zoom in on the start of https://www.google.co.uk/intl/en/ipv6/statistics.html https://www.google.co.uk/intl/en/ipv6/statistics.html you can see that 6to4+Teredo was more common than native until 2010. (Okay, that's combined with Teredo, but I think probably 6to4 is the majority of it because Windows will use 6to4 without needing a registry change or custom application behavior.) You see it as a special feature with rare usage because it competed with native and lost. People overwhelmingly preferred deploying v6 natively instead of deploying 6to4. Obviously more people would be using it if it was the only option, but if you're trying to come up with an alternative to the way v6 went then "an approach that v6 took but which nobody wanted to use when native v6 was the alternative" might not be a very promising place to start.
        7mo ago