Comment by xacky
1 day ago
The fact that we have yet to fully deprecate IPv4 should be considered a great failure in the tech industry's competence.
1 day ago
The fact that we have yet to fully deprecate IPv4 should be considered a great failure in the tech industry's competence.
Well the migration from IPv4 to IPv6 is probably less important and less impactful than climate change, and let's check the score on that...
:grimace:
one is close to hundreds of millions in cost and with likeminded stakeholders. the other is hundreds of trillions in costs with the entire human population as stakeholders.
... and yet IPv6 still taking its sweet time.
Point being that patterns on small scales match patterns on larger scales.
but climate change is not up to the tech industry
Depends on what you mean by 'tech'.
Decreasingly the case it would seem.
1 reply →
Then again, given some even failed to adopt the metric system ...
Also, that same tech industry has shown remarcable competence in working around IPv4's limitations.
This is quite similar situation indeed. It was once easier to adopt the metric system when the infrastructure was not yet as developed around the previous ones.
Austria-Hungary adopted the metric system in the 1870s. Back then: no cars, no highways, no speeding laws etc. Oxen-drawn wagons in the countryside were not built to a precise spec.
Only the railway, the architects and the artillery had to really switch. Ordinary people would still ask the grocer for half a pound of ham in the 1930s.
USA in the 1970s would have to remeasure all the land communications etc., or end up with a weird hybrid like the UK.
WHat we have in IPv4 and IPv6 is the weird UK-like hybrid...
Australia managed to do a complete† change over starting in the 1970s:
* https://en.wikipedia.org/wiki/Metrication_in_Australia
It's going to take decades, mostly waiting for the non-metric folks to die off probably and the raised-on-metric folks to grow up, but if you don't start you'll never finish.
† Can Aussie HNer confirm?
5 replies →
IPv4 is better than IPv6, and imperial is better than metric. I would like something to replace IPv4, but that thing shouldn't be IPv6 and probably won't be at this rate.
How are they better?
30 replies →
My digital calipers can display freedom fractions. It makes my eyes bleed.
It's actually a blessing for some, what would drive a company holding such a large capital of IPs to make it lose value by supporting IPv6?
Not enough supply/demand. AWS charge like $0.005/hr per IPv4 address
Why? It was designed and implemented by competent people and continues to work today.
If you have a dedicated IPv4 address, those behind NAT and CGNAT face significant throttling and false positive blocking. It's been made worse by scraper botnets.
It's the hobbyists who LARP as network engineers, and that end users and hiring managers can't tell the difference, who are holding everyone back.
Anyone who doesn't by default set up IPv6-only networks by default with NAT64 and DNS64, or who present any notion that IPv4 is somehow "okay", shouldn't have a job anywhere, not even an entry-level desktop support job.
IPv4 is perfectly and objectively fine on internal networks. IPv6 is overkill and way too complicated for most.
IPv6 can be selectively applied to say, NAT addresses, but other than that, IPv4 is just fine and your statement is incorrect.
> IPv4 is perfectly and objectively fine on internal networks. IPv6 is overkill and way too complicated for most.
Unless there's a merger/acquisition and the two companies both use 10.0.0.0.
Most home networks use 192.168, and so you can't use that in corporate environments, because the WFH people who VPN in could then have routing snags between local and remote locations.
Also, in your VPN software be sure to perhaps not use 172 addresses (like my previous job did), as some of those ranges are used by Docker by default, and so you can cause issues for developers.
But other than that IPv4 RFC 1918 is not complicated at all…
In theory IPv6 solves the problem by putting all of this under a single prefix (fc00::/8) and asking nicely that implementation/admins add 40 random bits to form their prefix. Which is plenty to prevent (almost all) eventual conflicts.
The thing is, asking nicely doesn't always work. Sure, automated tools like docker/incus/wireguard/tailscale will respect it. But admins who don't want to be stuck typing long addresses? Not so much. I've lost count of how often I encounter a network admin that manually set their prefix to some fcXX::, when it's not outright fc00::.
Of course you can (and should) blame this on admins and not on IPv6, but then the same could be said of IPv4 where adding entropy to 10.X.X.0 is the usual recommended way of doing things.
1 reply →
You can't selectively use IPv6 in the WAN and IPv4 in the LAN.
How would an IPv4 client send a packet to an IPv6 server? The IPv4 packet has only 4 bytes to spare for the destination address.
You can't.
Anything longer, even if it's just 1 bit, would require a new IP version.
You can run a 4to6 NAT, where specific v6 addresses (the ones you’re talking to) are aliased to reserved v4 addresses out of the PUA.
1 reply →
The "solution" is that IPv6-only servers do not exist and will never exist.
1 reply →
Alternatively, IPv4 simply does not scale effectively on the LAN, whereas IPv6 allows much simpler addressing and routing topologies. Simple = good.
No, backwards compatibility is competence.
> No, backwards compatibility is competence.
Creating an IPng was always going to be complicated:
* https://github.com/becarpenter/misc/blob/main/why6why.md
* https://datatracker.ietf.org/doc/html/rfc1671
For anyone curious as to the decision-making process, here are the criteria for what the IETF was looking for in an IPng:
* https://datatracker.ietf.org/doc/html/rfc1726
Here are the candidates that were floating around at the time, and the reason why the winner was chosen:
* https://datatracker.ietf.org/doc/html/rfc1752
This is very valuable, but not sure if you think it contradicts my comment.
I'm not saying that IPv6 is incompetent, or that IPv6 implementations break backward compatibility, or that the problem can be solved without breaking bc.
I'm saying that while IPv6 breaks bc itself, dual stack does not, and even full migrations can maintain bc or gracefully degraded.
In essence, not all implementations IPv6 are good, and not all migrations from IPv4 are responsible, if someone is blindly team IPv6 or blindly team IPv4 in general there's a lack of nuance.
It's impossible for a long address system to be compatible with a short address system. No one has ever found a way to make it work. Plenty of people think they have, but upon closer inspection, they haven't.
NAT is the only one that actually does work, and it's terrible.
i find NAT64 acceptable
Dual stack?
1 reply →