Back to Blog

The IPv6 Threat Landscape: Why Your Security Stack Needs Dual-Stack Support

IPv6 adoption has crossed the 50% mark globally, yet the majority of threat intelligence feeds and security tools still operate primarily in the IPv4 world. This gap creates a dangerous blind spot. Here's why it matters and what we're doing about it.

The IPv6 Blind Spot

Most fail2ban configurations only monitor IPv4. Most threat feeds only list IPv4 indicators. Most firewall rules are written for iptables (IPv4-only) rather than nftables (dual-stack). The result? Attackers who use IPv6 often fly under the radar.

Consider these attack vectors that are unique to or amplified by IPv6:

• IPv6 scanning: The massive address space makes traditional scanning impractical, but attackers use DNS harvesting, NDP cache analysis, and hitlist-based scanning
• Dual-stack attacks: Attacking a service on its IPv6 address while the security stack only monitors IPv4
• Extension header abuse: IPv6's extension headers can be used to bypass firewalls and IDS systems that don't properly parse them
• Privacy addresses (SLAAC): Temporary IPv6 addresses make attribution harder

ThreatChain's IPv6-Native Approach

We built ThreatChain with IPv6 as a first-class citizen, not a bolt-on:

Dual-Stack Threat Records

Every threat entry in ThreatChain supports both IPv4 and IPv6 targets:

{
    "target": "2001:db8::dead:beef",
    "target_type": "ipv6",
    "cidr_prefix": 128,
    "action": "block",
    "severity": "high"
}

CIDR notation works for both protocols — block a single address (/128) or an entire prefix (/48).

nftables Dual-Stack Enforcement

ThreatChain uses nftables with the inet family, which handles both IPv4 and IPv6 in a single ruleset:

table inet threatchain {
    set blocklist_v4 { type ipv4_addr; flags dynamic, timeout; }
    set blocklist_v6 { type ipv6_addr; flags dynamic, timeout; }

    chain input {
        ip saddr @blocklist_v4 drop
        ip6 saddr @blocklist_v6 drop
    }
}

When the enforcer polls the blockchain, it automatically categorizes threats and adds them to the appropriate set. No manual configuration needed.

IPv6 P2P Mesh

The blockchain itself communicates over IPv6. Our WireGuard mesh uses fd00:tc::/64 (ULA) for tunnel addresses, and the blockchain's P2P protocol runs over these encrypted IPv6 links. We operate under AS23026 with a /44 IPv6 allocation, giving us plenty of address space for our infrastructure and customer tunnels.

BGP Over IPv6

Our BIRD 2 configuration supports both IPv4 and IPv6 BGP sessions. Critical IPv6 threats can be blackholed at the network edge just like IPv4 threats:

protocol bgp customer_v6 {
    neighbor fd00:tc::cafe as 65000;
    local fd00:tc::1 as 64999;

    ipv6 {
        import none;
        export filter {
            if bgp_community ~ [(64999, 666)] then accept;
            reject;
        };
    };
}

What You Should Do

1. Audit your security stack: Does your IDS/IPS inspect IPv6 traffic? Does fail2ban monitor IPv6 connections?
2. Use dual-stack firewalling: Switch from iptables to nftables with the inet family
3. Include IPv6 in threat intelligence: Subscribe to feeds that include IPv6 indicators
4. Test your IPv6 exposure: Scan your own IPv6 addresses and verify your security controls work

ThreatChain handles all of this automatically. When you join the network, both IPv4 and IPv6 threats are enforced on all your nodes. Check out our Services page to get started.

---

Back to Blog