Does it? If you pretend IPv6 doesn't exist, sure, but that's like pretending UDP doesn't exist because all of your applications use TCP, or only logging traffic going to port 80 because you don't have HTTPS yet.
Every firewall I've come across has a default deny rule for incoming IPv6 traffic, giving the firewall the same properties as any IPv4 network. Host firewalls are the same; anything ranging from Windows Firewall to UFW and firewalld have presets to block all traffic except for the applications you've whitelisted. Once you get to huge enterprise routers managing routable IPv4 addresses and IPv6 addresses the situation may become different, but it's still not that much overhead.
The biggest problem with securing IPv6 seems to be ignoring it assuming that makes it disappear. If you configure your firewall to drop all IPv4 traffic not on a whitelist but somehow manage to forget to add the same rule for IPv6, you should re-evaluate your networking knowledge and maybe get up to speed with how the internet has changed since 2015.
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.
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.
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…
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:)
> but that's like pretending UDP doesn't exist because all of your applications use TCP, or only logging traffic going to port 80 because you don't have HTTPS yet.
In fairness, neither of those things would be unreasonable stances, given those conditions.
Every firewall I've come across has a default deny rule for incoming IPv6 traffic, giving the firewall the same properties as any IPv4 network. Host firewalls are the same; anything ranging from Windows Firewall to UFW and firewalld have presets to block all traffic except for the applications you've whitelisted. Once you get to huge enterprise routers managing routable IPv4 addresses and IPv6 addresses the situation may become different, but it's still not that much overhead.
The biggest problem with securing IPv6 seems to be ignoring it assuming that makes it disappear. If you configure your firewall to drop all IPv4 traffic not on a whitelist but somehow manage to forget to add the same rule for IPv6, you should re-evaluate your networking knowledge and maybe get up to speed with how the internet has changed since 2015.