← Back to context

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.

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:

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...

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?

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.

  • 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:

          So it's a matter of mathematical and physical fact that to expand
          the address size, you must change the protocol, and that means 
          [three] things immediately:
    
                You have to change the version number.
    
                You have to add new code to handle the new version.
    
          […]
    
                You need a coexistence technique so that updated systems, 
                with the new protocol, can connect to old systems that know 
                nothing of the new protocol.
    
          Two minutes of thought show that this third requirement has only 
          two solutions:
    
                (3A) Dual stack, in which the new machines speak both 
                     the old (IPv4) and new (IPng) protocol.
    
                (3B) Translation, in which something translates addresses
                     between the old and new protocols.
    

    * 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.