4 ms·

IPv4-with-more-bytes is not backwards compatible with IPv4. So you'd have to replace/upgrade every existing network stack, both hardware and software. To get,

IPv4-with-more-bytes is not backwards compatible with IPv4. So you'd have to replace/upgrade every existing network stack, both hardware and software. To get, basically, the same effect as moving to IPv6.

deleted 6mo ago
[deleted]
Galanwe 6mo ago
> IPv4-with-more-bytes is not backwards compatible with IPv4 Neither is IPv6 > To get, basically, the same effect as moving to IPv6 The only thing that IPv6 solves which is of interest to 99.99% of the users is having more adressable space. The rest of IPv6 features are either things that nobody asked for, or things which are genuinely worst compared to IPv4. I consider the mere fact of enabling IPv6 an unacceptable security risk, as I would now have to make sure my IPv4 and IPv6 firewall stack are perfectly mirroring each other. That would be trivial with IPv4-with-more-bytes, it's a nightmare with IPv6.
- mrsssnake 6mo ago
  Do NAT64 and just worry about IPv6 if not wanting dual stack. All of IPv6 features are just direct effects of having more space and not. Basically IPv6 "features" is just getting rid of IPv4 workarounds.
- vel0city 6mo ago
  > I would now have to make sure my IPv4 and IPv6 firewall stack are perfectly mirroring each other. You'd still have that in your IPv4-with-more-bytes, as you'll still probably end up running dual-stack to address those old-v4-only sites. Or you'd do the same with v6 and run a tunnel to translate those v4-only addresses to your v4-with-more-bytes. So you're in the same situation either way.
mprovost 6mo ago
There were backwards-compatible protocols proposed, such as EIP, but the committee chose a backwards-incompatible protocol for v6. Their assumption was that v4 would run out of space in a single-digit number of years and everyone would be forced to migrate. The past 30 years have shown that not to be the case. https://datatracker.ietf.org/doc/html/rfc1385 https://datatracker.ietf.org/doc/html/rfc1385
- Dagger2 6mo ago
  They went with SIPP, which was one of the backwards-compatible options. It should be kind of obvious from the vast number of backwards compatibility methods available in v6 that v6 is actually backwards compatible... but for some reason a lot of people either refuse to believe this or have double standards around what counts as compatibility.

deleted 6mo ago

[deleted]

Galanwe 6mo ago

> IPv4-with-more-bytes is not backwards compatible with IPv4 Neither is IPv6 > To get, basically, the same effect as moving to IPv6 The only thing that IPv6 solves which is of interest to 99.99% of the users is having more adressable space. The rest of IPv6 features are either things that nobody asked for, or things which are genuinely worst compared to IPv4. I consider the mere fact of enabling IPv6 an unacceptable security risk, as I would now have to make sure my IPv4 and IPv6 firewall stack are perfectly mirroring each other. That would be trivial with IPv4-with-more-bytes, it's a nightmare with IPv6.

mrsssnake 6mo ago
Do NAT64 and just worry about IPv6 if not wanting dual stack. All of IPv6 features are just direct effects of having more space and not. Basically IPv6 "features" is just getting rid of IPv4 workarounds.
vel0city 6mo ago
> I would now have to make sure my IPv4 and IPv6 firewall stack are perfectly mirroring each other. You'd still have that in your IPv4-with-more-bytes, as you'll still probably end up running dual-stack to address those old-v4-only sites. Or you'd do the same with v6 and run a tunnel to translate those v4-only addresses to your v4-with-more-bytes. So you're in the same situation either way.

mprovost 6mo ago

There were backwards-compatible protocols proposed, such as EIP, but the committee chose a backwards-incompatible protocol for v6. Their assumption was that v4 would run out of space in a single-digit number of years and everyone would be forced to migrate. The past 30 years have shown that not to be the case. https://datatracker.ietf.org/doc/html/rfc1385 https://datatracker.ietf.org/doc/html/rfc1385

Dagger2 6mo ago
They went with SIPP, which was one of the backwards-compatible options. It should be kind of obvious from the vast number of backwards compatibility methods available in v6 that v6 is actually backwards compatible... but for some reason a lot of people either refuse to believe this or have double standards around what counts as compatibility.