3 ms·
Well, yes, legacy. But, > …a bunch of lazy network admins in NA and the EU that don't want to learn the new tech… That’s a cheap shot, and it’s not called for
by klodolph 6y ago
Well, yes, legacy. But,
> …a bunch of lazy network admins in NA and the EU that don't want to learn the new tech…
That’s a cheap shot, and it’s not called for.
Network admins are paid to make the networks run. Anything else is less important. If your IPv6 network experiences some small problems, well, you’re going to hold on to IPv4 because small network problems can mean big inefficiencies or lost sales.
Just a few weeks ago I was on the phone with my WiFi router’s vendor for a couple hours or more because IPv6 traffic wasn’t working through it. I had narrowed the problem down to the router itself. It’s not necessarily that IPv6 is poorly tested or has technical problems, it’s that there’s a long tail of devices/configurations/software out there which screw it up, and it’s often cheaper to just use IPv4 rather than suffer even the minor inconveniences and troubleshooting sessions necessary to run IPv6.
It’s moving forward but it’s slow progress, and it’s not because network admins are lazy or stupid. It’s because there’s a lot of work to be done and not everyone has much of an incentive to do it at all.
- spicyramen 6y agoAgree. Moving IP addresses to IpV6 at any organization required huge planning and is normally not a business or competitive advantage. (In most cases)
- velvetz 6y agoDefinitely. At our company our network provider decided that it's better for us to use ipv6 from now on. For one day the customer support couldn't figure out what was wrong with our network. They even suggested that the recent heavy rain might have damaged the lines. Finally after a few struggles they mentioned in one sentence that they switched our region to ipv6 only, and that was when we, the customer, realized what's wrong. And obviously, we have a business plan. So that was one day of work without any internet.
- jacobwilliamroy 6y agoOne can really clean house if they understand networking well and pay close attention to what the WAN is doing. On the flip side, one can easily be ruined if the WAN is not considered during infrastructure planning.
- mrweasel 6y agoYeah, it's not the network admins, they want IPv6 too. If at all possible our network admins want IPv6 only networks, the sad fact is that it's not possible in most cases. We had to return stacks of Cisco equipment, because despite being brand new it had no IPv6 support. We should have checked of cause, but we just didn't imagine that you could buy IPv4 only equipment in 2020. Software is even worse, we have had software that advertised IPv6 support, so we build an IPv6 only solution, only to find out that the manufacturer has NEVER had a customer using their software on IPv6. They tested it six years ago and never followed up, meaning that IPv6 does actually work in the latest versions. Docker is another example, who in their right mind designed Docker to be a IPv4 only solution and then attempts to bolt on IPv6 later. It should have been IPv6 and then if you really needed it you could add an IPv4 ingress. Most of the issues we have experience using Docker could have been avoided by using IPv6 and dropping IPv4 all together.
- magicalhippo 6y ago> Software is even worse Indeed. Even stuff like pfSense has only rudimentary IPv6 support. And I guess software support is poor because they're still figuring out how to actually deploy IPv6, churning out new RFC's[1]. [1]: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-addressing-considerations-00 https://tools.ietf.org/html/draft-gont-v6ops-ipv6-addressing... (random example)
- iam-TJ 6y agoWhat is even more incredible in 2020 is that docker.com and hub.docker.com do not host on IPv6 .... and they're on AWS. We discovered this due to operating an IPv6-only network and having to deploy NAT64/DNS64* on the edge specifically for reaching hub.docker.com * NAT64/DNS64 was trivial to set up (Tayga + bind9) - took 2 hours for a networking apprentice