The IPv6 DDoS Surge Nobody Prepared For
For years, IPv6 was the protocol everybody deployed but nobody attacked. That assumption has collapsed. Over the past two years, the share of DDoS traffic carried over IPv6 has increased by more than 600%, according to data from multiple large transit providers and scrubbing services. The absolute volume is growing even faster as overall DDoS bandwidth continues to climb past the multi-terabit threshold.
The shift makes sense when you consider the adoption curve. Global IPv6 traffic now accounts for over 45% of total internet traffic measured by Google's public statistics. Major cloud providers, CDNs, and hosting platforms have been dual-stack for years. Mobile carriers in most countries route the majority of subscriber traffic over IPv6. The protocol is no longer a curiosity or a compliance checkbox. It is a primary transport layer for a large and growing share of production traffic.
As IPv6 adoption crosses from minority to near-parity with IPv4, attackers follow the traffic. Botnets composed of mobile devices, IoT hardware, and cloud instances increasingly operate on IPv6 by default. Amplification reflectors exist on both protocol versions. And critically, the defensive infrastructure that organizations spent a decade building for IPv4 DDoS often has significant gaps when it comes to IPv6.
The result is a growing blind spot. Organizations that invested heavily in DDoS detection and mitigation for their IPv4 infrastructure may be running with minimal or no equivalent coverage on their IPv6 prefixes. Attackers are beginning to exploit this asymmetry deliberately, targeting IPv6 addresses specifically because they know the detection coverage is thinner.
Why 128-Bit Addresses Break Traditional Defenses
The fundamental architectural difference between IPv4 and IPv6 creates challenges for DDoS defense that go beyond simply "supporting the new protocol." IPv4 has roughly 4.3 billion addresses. IPv6 has 340 undecillion. This is not just a bigger number. It is a qualitatively different problem space that breaks assumptions baked into decades of security tooling.
Per-IP Blacklisting Does Not Scale
In IPv4, per-IP blocklists are a viable (if imperfect) defense mechanism. You can maintain a blocklist of millions of IPv4 addresses in a hardware ACL or firewall rule set that fits in TCAM. The entire IPv4 address space can be stored in a bitmap that fits in memory on a commodity server.
In IPv6, a single /48 allocation — the standard size for a single site — contains 1.2 trillion possible host addresses. An attacker with access to even a modest /64 subnet can generate traffic from 18.4 quintillion unique source addresses. No blocklist, no TCAM, and no hash table can track individual addresses at this scale. Per-IP reputation scoring, which is a cornerstone of many IPv4 DDoS mitigation systems, becomes computationally infeasible when the attacker can rotate through billions of source addresses per second.
The practical implication is that any defense strategy built on tracking or blocking individual source IPs must be redesigned for IPv6. Effective IPv6 filtering requires prefix-based approaches — blocking or rate-limiting at the /48, /56, or /64 level rather than the /128 level. But many existing tools were not designed with this aggregation in mind.
Flow Analysis at Scale
NetFlow v9 and IPFIX both support IPv6, but the larger address fields mean each flow record consumes more memory and bandwidth. A router exporting millions of flow records per second will generate significantly more collector load for IPv6 traffic than for equivalent IPv4 traffic. At typical sampling rates of 1:1000 or 1:2000, the combination of larger records and massive source address diversity can overwhelm flow collectors that were sized for IPv4 workloads.
More fundamentally, flow-based anomaly detection that relies on identifying "top talker" source IPs struggles when the attacker spreads traffic across millions of unique /128 sources. No single source IP rises to the top of any ranking. The traffic looks like a broad distribution from many sources, which is exactly what legitimate traffic looks like on a busy network.
IPv6-Specific Attack Vectors
Beyond the address space challenges, IPv6 introduces protocol-specific attack vectors that have no direct equivalent in IPv4. These vectors exploit features that were designed to make IPv6 more flexible but also create new opportunities for abuse.
Extension Header Floods
IPv6 replaces IPv4's fixed header options with a chain of extension headers. A packet can carry a Hop-by-Hop Options header, a Routing header, a Fragment header, a Destination Options header, and others, all chained together before the upper-layer payload. Each extension header must be processed in order by routers (for hop-by-hop) or by the destination host (for all others).
Attackers craft packets with long chains of extension headers, sometimes nesting multiple layers of options within each header. These packets force the receiving host or intermediate router to parse through the entire chain before it can classify or drop the packet. On hardware-based forwarding platforms, packets with extension headers often get punted to the slow path (CPU processing) because the ASIC cannot parse arbitrary header chains at line rate. A relatively low-volume flood of extension header packets can exhaust the CPU on a router or firewall that would handle the same bandwidth of simple UDP packets without breaking a sweat.
# Example: IPv6 packet with chained extension headers
# Each header forces additional parsing before the payload is reached
IPv6 Header (Next Header: Hop-by-Hop)
Hop-by-Hop Options (Next Header: Destination)
Destination Options (Next Header: Routing)
Routing Header Type 2 (Next Header: Fragment)
Fragment Header (Next Header: Destination)
Destination Options (Next Header: UDP)
UDP Payload (attack data)
# Many firewalls and IDS systems fail to parse past
# the 3rd or 4th extension header in the chain
Fragmentation Attacks
In IPv6, fragmentation is handled exclusively by the source host, not by intermediate routers. The Fragment extension header allows the sender to split packets into fragments that the destination must reassemble. This design decision was intended to improve router performance, but it creates a potent attack vector.
An attacker can send thousands of first fragments (offset 0) without ever sending the corresponding subsequent fragments. The destination host allocates memory for each fragment reassembly context, waiting for the remaining pieces that will never arrive. This consumes memory on the target until the reassembly timeout expires. On many operating systems, the default fragment reassembly timeout is 60 seconds, meaning each incomplete fragment holds memory for a full minute.
A sustained flood of incomplete IPv6 fragments can exhaust the target's fragment reassembly buffers, causing legitimate fragmented traffic to be dropped. Some implementations also experience CPU exhaustion from the overhead of managing millions of pending reassembly contexts.
NDP Exhaustion
The Neighbor Discovery Protocol (NDP) is the IPv6 equivalent of ARP. When a router needs to forward a packet to a destination on a directly connected subnet, it sends a Neighbor Solicitation to discover the link-layer address of the destination. If the destination does not respond, the router retries several times before giving up.
In an NDP exhaustion attack, the attacker sends packets to random addresses within a target's directly connected /64 subnet. For each previously unseen destination, the router creates a Neighbor Cache entry in the INCOMPLETE state and sends a Neighbor Solicitation. Since most of these addresses do not have actual hosts behind them, no response comes. The router's Neighbor Cache fills with incomplete entries, consuming memory and CPU cycles for the solicitation retries.
A /64 subnet contains 18.4 quintillion addresses. The attacker can generate destination addresses faster than the router can time them out. This attack can crash or severely degrade the performance of the last-hop router, taking the entire subnet offline. It is particularly devastating because it targets the router infrastructure rather than any individual server.
# NDP exhaustion: attacker sends traffic to random /128 addresses # within the target's connected /64 subnet Target subnet: 2001:db8:abcd:1::/64 Attack traffic destinations: 2001:db8:abcd:1:a1b2:c3d4:e5f6:7890 2001:db8:abcd:1:f00d:cafe:beef:dead 2001:db8:abcd:1:1234:5678:9abc:def0 ... (millions of random addresses per second) Router response for EACH new address: 1. Create Neighbor Cache entry (INCOMPLETE) 2. Send Neighbor Solicitation (multicast) 3. Wait for response (timeout: several seconds) 4. Retry solicitation (up to 3 times) 5. Mark entry FAILED, eventually garbage collect Result: Router CPU and memory exhaustion
IPv6 Tunneling Abuse
Transition mechanisms like 6in4, 6to4, Teredo, and ISATAP encapsulate IPv6 packets inside IPv4. These tunnels are often configured automatically and may bypass security controls that only inspect the outer IPv4 header. An attacker can send malicious IPv6 traffic encapsulated in seemingly benign IPv4 packets, avoiding detection by firewalls and IDS systems that do not inspect tunnel payloads.
The attack surface is broader than many organizations realize. Teredo, in particular, can be enabled by default on some Windows configurations, creating IPv6 connectivity (and attack exposure) on networks that believe they are IPv4-only. Traffic arriving through these tunnels may not be visible to network-level monitoring at all if the monitoring infrastructure does not decode the encapsulation.
Why Most Detection Tools Treat IPv6 as an Afterthought
The gap between IPv4 and IPv6 detection coverage in most organizations is not a deliberate choice. It is the result of tools and processes that were built for IPv4 and only partially extended to support IPv6.
Many on-premise DDoS detection appliances were designed in an era when IPv6 traffic was negligible. Their core detection algorithms operate on IPv4 flow data, and IPv6 support was added later as a feature checkbox. In practice, this often means that IPv6 traffic is parsed and displayed but not subjected to the same depth of analysis. Baselines may not be maintained separately for IPv6 prefixes. Anomaly detection thresholds may not account for the different traffic profiles of IPv6 versus IPv4.
Flow-based detection systems face the scaling challenges described earlier. Collectors sized for IPv4 flow volumes may not have the capacity to ingest and analyze the larger IPv6 flow records at the same fidelity. When resources are constrained, IPv6 analysis is often the first thing to degrade.
Even organizations with modern detection tools often have configuration gaps. IPv4 prefixes are meticulously defined in the detection system's network model, with per-prefix baselines and alerting rules. IPv6 prefixes may be missing from the configuration entirely, or lumped into a broad "all other traffic" category that lacks the granularity needed for effective detection.
The most dangerous IPv6 DDoS scenario is not a new attack vector. It is the same UDP amplification flood that would be detected in seconds on IPv4, arriving on an IPv6 prefix that nobody remembered to add to the monitoring configuration.
Auditing Your IPv6 DDoS Readiness
Before you can close the IPv6 blind spot, you need to understand how wide it is. Here is a practical audit checklist that covers the most common gaps.
- Inventory your IPv6 prefixes: List every IPv6 prefix announced via BGP and every prefix assigned to internal interfaces. Compare this list against the prefixes configured in your DDoS detection system. Any prefix present in your routing table but absent from your detection configuration is a blind spot.
- Verify flow export: Confirm that your routers are exporting flow records for IPv6 traffic, not just IPv4. Check that the flow collector is ingesting and indexing IPv6 flows. Many routers support IPv6 flow export but have it disabled by default.
- Check baseline coverage: If your detection system uses dynamic baselines, verify that baselines exist for IPv6 traffic on every monitored interface and prefix. Some systems maintain IPv4 baselines automatically but require manual configuration for IPv6.
- Test extension header handling: Send test traffic with IPv6 extension headers through your detection pipeline. Verify that packets with Hop-by-Hop, Routing, and Fragment headers are parsed correctly and that the detection system can classify the upper-layer protocol. Many tools fail to look past extension headers and classify all such traffic as "unknown protocol."
- Review mitigation capabilities: Confirm that your mitigation tools (RTBH, FlowSpec, scrubbing center steering) work with IPv6 prefixes. Test blackholing an IPv6 /128 and verify that the route propagates correctly to your upstream providers.
- Audit tunnel exposure: Scan your network for active IPv6 transition tunnels (6to4, Teredo, ISATAP). These may exist on individual hosts even if the network does not officially support IPv6. Any tunnel endpoint is a potential ingress point for IPv6 DDoS traffic that bypasses your standard monitoring.
Practical Defense: Closing the Blind Spot
Closing the IPv6 DDoS gap requires both configuration changes to existing tools and, in some cases, architectural changes to how you approach detection and mitigation.
Monitor Both Stacks Equally
The single most impactful step is to ensure that every IPv6 prefix in your infrastructure has the same detection coverage as its IPv4 counterpart. This means per-prefix baselines, per-protocol anomaly detection, and alerting rules that cover IPv6 traffic at the same granularity as IPv4. If your detection system cannot provide this, it is time to evaluate alternatives that can.
Adopt Prefix-Based Filtering
Replace per-IP blocklists with prefix-based rate limiting and filtering for IPv6. When you detect malicious traffic from a range of IPv6 sources, block at the /48 or /64 level rather than attempting to enumerate individual /128 addresses. This matches the way IPv6 addresses are actually allocated and reduces the size of your filter tables by orders of magnitude.
Harden NDP
Protect your routers against NDP exhaustion by configuring Neighbor Cache limits and implementing ND inspection where supported. Limit the size of the Neighbor Cache to prevent unbounded growth. Configure aggressive garbage collection for incomplete entries. On Cisco IOS-XR, the ipv6 nd cache expire and ipv6 nd nud retry commands allow you to tune these parameters. On Junos, the neighbor-discovery stanza under the interface configuration provides similar controls.
Filter Extension Headers at the Border
Most legitimate traffic does not use unusual extension header chains. Consider filtering packets with Routing Header Type 0 (deprecated and known to be exploitable), packets with excessive numbers of chained headers, and packets with Hop-by-Hop Options headers from external sources (these should only appear from directly connected neighbors). RFC 7045 provides guidance on which extension headers to permit and which to filter.
Disable Unused Tunnel Mechanisms
If your network supports native IPv6, there is no reason to allow 6to4, Teredo, or other transition mechanisms. Block protocol 41 (IPv6-in-IPv4 encapsulation) at your border if you do not use any IPv6 tunneling. Disable Teredo on endpoints via group policy. Every unnecessary tunnel is an unmonitored ingress point.
Host-Level Detection Covers All Traffic
Flowtriq's agent-based approach sidesteps many of these challenges by monitoring traffic at the host level. The agent captures packets on the network interface regardless of IP version. IPv4 and IPv6 traffic are both analyzed against per-node dynamic baselines, with protocol classification that handles extension headers natively. There is no separate configuration step for IPv6 — if traffic reaches the host, the agent sees it and baselines it.
This is particularly valuable for detecting NDP exhaustion and extension header attacks, which are often invisible to network-level flow analysis. The agent on each host in the targeted subnet observes the symptoms of these attacks (unusual protocol distributions, spikes in ICMPv6 traffic, or elevated packet rates from unknown sources) and reports them as anomalies without requiring prefix-level aggregation at a central collector.
The Road Ahead
IPv6 adoption will continue to grow. Within the next few years, IPv6 will carry the majority of internet traffic globally, not just on mobile networks. The share of DDoS traffic on IPv6 will grow proportionally, and attackers will increasingly develop IPv6-specific techniques that exploit the protocol's unique characteristics.
Organizations that close the IPv6 blind spot now — before they experience an IPv6-targeted attack that their tools miss — will be in a far better position than those who wait for a production incident to expose the gap. The audit checklist above takes a few hours to complete. The configuration changes to bring IPv6 detection to parity with IPv4 may take a few days. Compared to the cost of an undetected DDoS attack persisting for hours because it arrived on the "wrong" IP version, that is time well spent.
IPv6 covered by default. Flowtriq's per-node agent monitors all traffic on the interface regardless of IP version. No separate configuration, no flow export gaps, no blind spots. Start your free trial and see full-stack visibility across IPv4 and IPv6 in minutes.