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.
Instead you could just choose ipv4 only and reduce a lot of complexity. Sure there are also downsides -- if you're in a large org and are running out of RFC1918 space, or you're rationing it to smaller than /24 networks, that can be a pain (I don't see a benefit of more than 256 host addresses on a subnet as that's already far to large a broadcast domain)
> 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.".)
1. Support IPv4 and IPv6.
2. Support only IPv4.
#2 has essentially no downsides and is radically simpler.
That's my point. It's not terrible to start a new project without IPv6 support, because adding IPv6 support adds a ton of complexity for almost no benefit.
I never claimed or insinuated that you recommend dropping IPv4. If I thought your recommendation was to drop v4, my argument about the complexity of dual-stack would've made no sense.
Check my handle. I'm not who you seem to think I am.
> ...adding IPv6 support adds a ton of complexity for almost no benefit.
That doesn't at all match my experience with IPv6 support in greenfield projects for the past decade+. You actually have to do extra work to make them IPv4-only. Remember that the statement you initially responded to said "It's a terrible it to start a new project in 2024..."
> Check my handle. I'm not who you seem to think I am.
Sorry, I didn't notice. Pretend I said "they" rather than "you".
> > ...adding IPv6 support adds a ton of complexity for almost no benefit.
> That doesn't at all match my experience with IPv6 support in greenfield projects for the past decade+. You actually have to do extra work to make them IPv4-only. Remember that the statement you initially responded to said "It's a terrible it to start a new project in 2024..."
Huh, I never found it difficult to ... not add an AAAA DNS record to point to a server. It surprises me that you find that to be extra work.
Have you attempted to make greenfield software written in 2024 support only IPv4 addresses and be deliberately incompatible with IPv6 addresses? It's a lot more work than just using what the standard libraries give you and just getting support for v4 and v6.
Now the software itself would probably work v6 if you set up the infrastructure for it, but that's not what I'm talking about. (I don't know for sure that it works with v6 though, never tested)
I know for sure that I've written some software before which doesn't work with IPv6 because the buffer I pass to gethostbyname is 4 bytes, but to be fair I haven't written such software in 2024. I have also written software to configure a device's interfaces and routing tables which only does DHCP4 and only configures v4 addresses, but that was in 2023 not 2024, maybe dhcp4 would've magically worked with IPv6 if I had done it this year
Hmm:
> The gethostbyname*(), gethostbyaddr*(), herror(), and hstrerror() functions are obsolete. Applications should use getaddrinfo(3), getnameinfo(3), and gai_strerror(3) instead.
* https://man7.org/linux/man-pages/man3/gethostbyaddr.3.html
Using gethostbyname turned out to be pretty easy by the way, I wouldn't say it was a lot more work than using getaddrinfo
If you're with AWS, you'll be charged for IPv4 public addresses:
* https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...
If you want to 'own' IPv4 addresses, that'll cost you as well:
* https://auctions.ipv4.global
Certainly some will be needed for 'legacy' purposes for the foreseeable future, but the more you can reduce the use of them at your edge, the less money you'll be shelling out.
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.