Over on the Fediverse, I recently saw a thought-provoking remark by Michael Gebis (via):

If I were an evil threat actor, I'd be learning as much about #ipv6 as possible right now. I'm convinced that many companies that say they "aren't using" IPv6 are in reality just ignoring IPv6, and it would be easy to set up a "shadow network" consisting of IPv6 traffic where you could get away with murder. Nobody at the company is logging IPv6 traffic and events, none of the tools are configured to monitor it, and a large majority of the staff knows nothing about it.

"But we disable IPv6!"

Really? On your users mobile devices? On printers? On random IoT devices? And most of all, on your remote user's networks? Good luck, my guy.

This got me thinking about what I'll call our passive exposure to IPv6. By that I mean whatever exposure we get from having IPv6 enabled on random devices, and perhaps automatically configured by systems or deliberately set up by a threat actor. For example, could a threat actor use IPv6 to bypass firewall protections or pass traffic in ways that would be invisible to our normal monitoring?

So far, we don't have IPv6 set up on any of our networks, and as a result we have no deliberate IPv6 network to network routing (or public IPv6 address assignment through any of DHCP6, SLAAC, or static assignment). However, as is the way of the world these days almost all of our servers have IPv6 enabled and they've assigned themselves fe80::/10 link local IPv6 addresses. It's likely that people's desktops, laptops, and mobile devices have done similarly on the networks where they live. When we look at general network traffic with tools like tcpdump, we do see a certain amount of IPv6 traffic trying to happen (using fe80::/10 link local addresses from what I've seen).

All of our firewalls explicitly block IPv6 traffic, and our core router doesn't have any IPv6 routes (because we have no IPv6 networks). A threat actor that wanted to use plain IPv6 across network boundaries would have to compromise one or more firewall rule sets, and getting plain IPv6 routing to the outside world would be quite complex. However, because we don't have IPv6 active on our own networks, we probably wouldn't notice if a threat actor set up a DHCP6 or SLAAC server that advertised itself as an IPv6 gateway to the local network. The attacker would have to tunnel the traffic in and out through IPv4, but there are various options for that that we probably wouldn't notice.

(Our core router might automatically start routing IPv6 traffic between our public subnets if those subnets started advertising appropriate IPv6 bits, but I don't know. However, those subnets can already reach each other with IPv4, and we're not doing traffic monitoring on the core router.)

Machines on internal networks that don't have port isolation can talk to each other with IPv6 (using link local addresses or addresses handed out by a threat actor), but then they can already talk to each other with IPv4. Machines on port isolated internal networks should still be port isolated from each other even if they use IPv6, but I admit we haven't tested the behavior of our switches to be completely sure of that.

(Port isolation is theoretically an Ethernet layer thing, not an IP layer one, but switches are extra smart these days so one is never entirely sure.)

We mostly don't use IP filtering on servers themselves, only on firewalls, so we don't have to worry about server IP filtering not being set up for IPv6 (an issue that I once had on my home machine). Where we do have some IP filtering, it's in the form of a default deny with a restricted positive allowance (for example, systemd's IP access controls or Apache access controls); this means that using an IPv6 address to access the service instead of an IPv4 address wouldn't bypass access restrictions; you specifically have to have the right IPv4 IP address.

We handle our DNS ourselves, so compromising our DNS infrastructure to add IPv6 addresses for some of our services would already be a pretty bad compromise by itself. We're no more or less likely to notice the addition of IPv6 records than we are to notice any other DNS change that doesn't visibly and clearly degrade services. I can imagine that the addition of IPv6 records might be able to do some damage because it might let an attacker get TLS certificates for some of our names and intercept the traffic of outside people on networks with IPv6 support.

(To avoid people noticing the service not working, the attacker could then send the traffic to the original server via IPv4.)

So on the whole I think we have a low passive exposure to IPv6 issues. A lot of this comes down to the long ago decision to explicitly block IPv6 traffic on all of our firewalls, even though we didn't (and still don't) have any IPv6 traffic.