Comment by kstrauser

Comment by kstrauser 18 hours ago

20 replies

I didn't recommend dropping IPv4. It's a terrible it to start a new project in 2024 without IPv6 support though. It's easy enough to build in from the beginning that there's not any real reason not to go for it.

And running a dual stack is trivially easy for almost everyone using it. That chart has almost half of Google's users coming in via IPv6. I promise you less than 1% of that 50% have ever even heard of IPv6, let alone done a single thing to configure it. With my ISP I'd have to go out of my way to turn it off, which I haven't done because this isn't 2008 where it broke things more often than never.

mort96 18 hours ago

> It's a terrible it to start a new project in 2024 without IPv6 support though.

Why? Radical complexity reduction at essentially no cost to yourself or your customers seems like a tempting proposition.

  • kstrauser 18 hours ago

    Exactly! IPv4 management is hideous compared to IPv6 once you grok it. The sooner you upgrade to it, the sooner you can deprecate horrid mitigations like NAT.

    • LegionMammal978 17 hours ago

      Out of curiosity, what parts of NAT management tend to be so horrible in practice?

      • kstrauser 17 hours ago

        The fact that it exists. I was a network engineer before NAT became a common thing and remember how it use to be when nodes on the network were legitimately peers. NAT is a bletcherous band-aid for the fact there are more people than 32 bit numbers. Now we're seeing true abominations like CGNAT. That stuff needs to be lost to the realm of scary legends told late at night.

    • mort96 17 hours ago

      You're missing the point, I believe intentionally. You can't get away from IPv4 as long as you have users who can't access IPv6-only servers. All your users and potential users can access IPv4-only servers.

      • cesarb 16 hours ago

        > All your users and potential users can access IPv4-only servers.

        Not all servers are user-accessible. For instance, a database server or a NAS server might only be accessed by other servers within the same organization. Using IPv6 between these internal-only servers, instead of RFC 1918 addresses, can simplify things.

      • rstuart4133 11 hours ago

        > You can't get away from IPv4 as long as you have users who can't access IPv6-only servers.

        That depends on your definition of "can't get away from". Your users can live on a IPv6 only lan and have the IPv4 world available to them. IPv6 supports 4 in 6 - ie you can embed IPv4 addresses in IPv6, so all you need is a gateway that translates IPv4 to IPv6 for them.

        I've done it. At a conference, to unsuspecting users. All phones support IPv6 well, so they didn't notice. Not one complaint - I was blown away by how well it all worked.

        It was done because some noisy attendees insisted on being assigned routable IP addresses. That can be difficult to provide with IPv4 for obvious reasons, whereas ISP's will happily hand you thousands of billions of IP{v6 routable addresses, for free.

        I set up the gateway myself, rolling my own using a linux box I had lying around. Adding the 4 in 6 capabilities is maybe an hours work on top of all the other setup you have to do on the box, and that includes googling to find what tools you need and how to configure them. It's not hard.

      • zokier 17 hours ago

        On the other hand only your edge load balancers need dual-stack, everything behind them can be v6-only.

      • simoncion 17 hours ago

        I think you're misunderstood what you quoted:

        > It's a terrible it to start a new project in 2024 without IPv6 support though.

        That does not preclude ALSO supporting IPv4.

        Remember that for many technical folks out there, the default is "Only do IPv4 support" which is (IMO) just batshit stupid.

        (Do also note that the sentence immediately prior to the one you quoted is "I didn't recommend dropping IPv4.".)