[UpToTheSky]

Its not just firewalls.

Its also all kinds of code that interacts with the internet in all kinds of ways. Extending all that code to two kinds of IPs, writing tests, setting up two types of IPs in development, staging and production, monitoring real life implications ... that would be a huge cost with no benefit at all.

[jeroenhd]

If you're writing code, you'll be either manually specifying the IP address family (so there's no real IPv6 risk) or you're probably using middleware that does all the hard parts for you anyway. If anything, I'm annoyed how hard it is to get a socket listening on both IPv4 and IPv6 in many low level libraries. I just want a socket to receive data on, who cares what address family it's from.

In my experience, IPv6 Just Works (tm) with modern software. There are some mid 00's frameworks for blacklisting abusive hosts that can't parse IPv6 addresses, or don't understand the /64 subnet you need to treat as a single IP address, but that's all I've ever run into. If anything, that gave me an excuse to finally get rid of an old Perl network filter running on my server.

I'm not sure how many tests the average piece of software needs that deals with the type of address family connecting. I suppose it matters if you want to test your rate limiting middleware or your logging library? That should only matter for the vendored code of course because modern libraries all have those tests themselves already. It's not like you need to run and write every test twice, only one or two very specific subcomponents if any.

If you're writing firewalls or kernels or router firmware then yeah you'll have your hands full with this stuff, but that's far from the standard developer experience. In those cases, IPv6 is a reality as much as TCP and UDP are.

[znpy]

> if you're writing code, you'll be either manually specifying the IP address family (so there's no real IPv6 risk)

AF_ANY is a thing, and it’s a best practice.

gethostaddr (iirc) was the old interface, but nowadays getaddrinfo is almost the default and supports AF_ANY.

[znpy]

To add a trivial example: if an application is coded well, it’s ready to connect to hosts both on ipv4 and ipv6, in the sense that when resolving a dns name, it will ask for addresses of any kind (unless it supports being explicitly told to only use ipv4).

So now you’re getting a record with multiple ip addresses, some of which are ipv6, but ipv6 is blocked… there you go with random connection delays and possibly timeouts.

Ipv6 exists and it’s getting more and more adoption, no matter if some people keep their head under the sand…

[kps]

> multiple ip addresses, some of which are ipv6, but ipv6 is blocked… there you go with random connection delays and possibly timeouts.

RFC6555 “Happy Eyeballs” discusses this.

[xemdetia]

A/AAAA records are a special sort of hell to debug remotely. "My browser can find it but I can't ping it! What do you mean ping6?"

In some environments that is maddening and I don't blame people for just deciding not to either at all or only translating at WAN.

[meindnoch]

For one the BSD socket interface for IPv6 supports IPv4 as well via the ::FFFF: prefix: https://www.ibm.com/docs/it/i/7.1?topic=families-using-af-in...

[ElectricalUnion]

> that would be a huge cost with no benefit at all.

Internet facing IPv6 infrastructure is usually much cheaper that their equivalent IPv4 enabled peers.

So supporting IPv4 can be the huge cost with no benefit at all, if all your clients/peers can use IPv6

[yjftsjthsd-h]

> if all your clients/peers can use IPv6

Including the case where you have something else in the middle already - for example, if you're fronting a website through cloudflare, then you can only have IPv6 on your server and still support dual-stack for clients:)