6 ms·

Dual stack is the problem, we've still got devices which are ipv4 only. I've never seen anything that's ipv6 only. Even on my standard linux laptop, and corpor

by iso1631 16d ago

Dual stack is the problem, we've still got devices which are ipv4 only. I've never seen anything that's ipv6 only. Even on my standard linux laptop, and corporate windows laptop, with the hack of DNS64, I still have issues with my ipv6 subnet. Yet I have no problem with my ipv4 subnets. So I don't bother with ipv6 - it's a toy. There is no benefit at all to me, but I can't get rid of IPv4 because some devices won't work with ipv6, and others will work but have bugs. The ivory towers felt "we know best, everyone will move to us, we don't need backwards compatibility". That arrogance put ipv6 back probably 30 years, maybe more. Building in backward compatibility at the protocol level (so 464 etc) would have removed the need for other hacks (dns64) and allowed a trivial transition.

jcgl 16d ago
Yep, agreed on pretty much all counts. The end goal is obviously the same for both dual-stack and translation technologies. But the latter makes things so much lower risk and gives you (the network operator) actual progress and a chance to simplify along the way. Providing IPv4-as-a-service is an actual plausible thing, compared to dual stack's now-draw-the-rest-of-the-owl vision.
jcgl 16d ago
> So I don't bother with ipv6 - it's a toy. Since I can't edit my other comment: I don't agree with this. I agree with the challenges of v6 that wouldn't be there if translation had been prioritized from the start, and with your characterization of DNS64 as a hack.
- iso1631 15d ago
  At work I can't see being able to drop ipv4 for at least 20 years due to applications and hardware which still relies on ipv4 (I've got some endpoints which don't even support igmpv2!) I still haven't had a single failure for someone who can't reach an ipv4 endpoint. As such I see it as just a toy.
  - jcgl 15d ago
    I'm not suggesting dropping v4 connectivity altogether. I'm suggesting migration to a v6-only core by providing IPv4 as a service via 464XLAT, IPv6-Mostly, or only offering IPv4 to select network segments using SIIT-DC-2xlat: https://nicmx.github.io/Jool/en/intro-xlat.html#siit-dc-dual-translation-mode https://nicmx.github.io/Jool/en/intro-xlat.html#siit-dc-dual...

by iso1631 16d ago

jcgl 16d ago

Yep, agreed on pretty much all counts. The end goal is obviously the same for both dual-stack and translation technologies. But the latter makes things so much lower risk and gives you (the network operator) actual progress and a chance to simplify along the way. Providing IPv4-as-a-service is an actual plausible thing, compared to dual stack's now-draw-the-rest-of-the-owl vision.

jcgl 16d ago

> So I don't bother with ipv6 - it's a toy. Since I can't edit my other comment: I don't agree with this. I agree with the challenges of v6 that wouldn't be there if translation had been prioritized from the start, and with your characterization of DNS64 as a hack.

iso1631 15d ago
At work I can't see being able to drop ipv4 for at least 20 years due to applications and hardware which still relies on ipv4 (I've got some endpoints which don't even support igmpv2!) I still haven't had a single failure for someone who can't reach an ipv4 endpoint. As such I see it as just a toy.
- jcgl 15d ago
  I'm not suggesting dropping v4 connectivity altogether. I'm suggesting migration to a v6-only core by providing IPv4 as a service via 464XLAT, IPv6-Mostly, or only offering IPv4 to select network segments using SIIT-DC-2xlat: https://nicmx.github.io/Jool/en/intro-xlat.html#siit-dc-dual-translation-mode https://nicmx.github.io/Jool/en/intro-xlat.html#siit-dc-dual...