IPv6 is now a standard part of many service provider, hosting, data centre and enterprise networks. As more services become reachable over IPv6, network operators also need to make sure that their DDoS monitoring covers IPv6 traffic properly.
IPv6 DDoS attacks are no longer unusual or small-scale. Recent industry telemetry has recorded IPv6 attacks exceeding 1 Tbps, while the amount of IPv6 traffic requiring active DDoS mitigation has also increased significantly.
For operators running dual-stack or IPv6 networks, IPv6 visibility and mitigation therefore need to be part of the production DDoS strategy, not an additional capability added later.
At a basic level, DDoS attacks do not become fundamentally different because the destination uses IPv6.
A UDP flood is still a UDP flood. A TCP SYN flood can target an IPv6 service in much the same way as an IPv4 service. High packet-rate attacks can put pressure on routers, firewalls and servers regardless of which IP version carries the traffic.
There are, however, some differences in IPv6 that monitoring and mitigation systems need to account for.
What does an IPv6 DDoS attack look like?
Most common network-layer DDoS attacks have direct IPv6 equivalents.
For example, an attacker can direct a large UDP flood towards an IPv6 address such as:
2001:db8:100::1234
The objective is the same as with IPv4: consume available bandwidth or overwhelm the packet-processing capacity of equipment or services.
The same applies to TCP attacks. Large numbers of TCP SYN packets can be sent towards an IPv6 service, while very high packet rates can affect routers, firewalls, load balancers and servers.
ICMP also exists in IPv6 as ICMPv6. It deserves some additional care because ICMPv6 is used for important IPv6 functions, including Neighbor Discovery and error signalling. Blocking all ICMPv6 traffic indiscriminately is therefore generally not a good mitigation strategy.
For DDoS detection, the core measurements remain familiar:
- bits per second;
- packets per second;
- flows per second where the telemetry source provides them;
- TCP, UDP and ICMP traffic;
- TCP SYN traffic.
The important requirement is that these measurements are collected and analysed for IPv6 as well as IPv4.
What is different about IPv6?
The most obvious difference is the size of the address space.
IPv6 uses 128-bit addresses, and operators routinely work with prefixes such as /48, /56 and /64. A monitoring system therefore needs to handle IPv6 networks efficiently and correctly determine which traffic belongs to the monitored network.
IPv6 packet handling also differs in some areas.
Optional information can be carried in IPv6 extension headers between the IPv6 header and an upper-layer protocol such as TCP or UDP. Fragmentation also works differently: routers do not fragment IPv6 packets in transit; fragmentation is performed by the source using an IPv6 Fragment header.
For most operators these details are not something they need to think about during every DDoS incident, but they do matter to the software receiving and interpreting network traffic.
There is also a simpler operational issue: visibility.
A network may have mature IPv4 DDoS monitoring but much less visibility into its IPv6 traffic. Enabling IPv6 on routers and services does not automatically mean the existing monitoring stack is collecting and analysing it.
Monitoring IPv6 traffic with FastNetMon
FastNetMon Advanced can process IPv4 and IPv6 traffic in the same deployment.
Operators configure the IPv4 and IPv6 prefixes that belong to their network. FastNetMon uses this information to classify traffic direction and maintain counters for monitored networks and hosts.
IPv6 traffic can be supplied using telemetry that supports IPv6, including NetFlow v9, IPFIX and sFlow, as well as mirrored packet traffic.
For NetFlow deployments, the export format matters. IPv6 flow information requires an IPv6-capable export format such as NetFlow v9 or IPFIX.
FastNetMon provides dedicated IPv6 counters that make it straightforward to confirm that IPv6 traffic is being received and classified correctly:
sudo fcli show total_traffic_counters_v6 sudo fcli show network_counters_v6 sudo fcli show host_counters_v6
Traffic for an individual IPv6 host can also be checked with:
sudo fcli show single_host_counters_v6 2001:db8:100::1234
FastNetMon also provides IPv6 support in fastnetmon_client:
sudo fastnetmon_client -ipv6
This is useful during deployment because operators can verify IPv6 visibility before enabling any automated attack actions. In addition to CLI tools, FastNetMon LiveView provides a visual view of current IPv4 and IPv6 traffic, which is useful for confirming visibility during deployment and for day-to-day operations:
Detecting IPv6 DDoS attacks
FastNetMon uses traffic counters and configurable thresholds to detect abnormal traffic towards monitored hosts.
Available threshold types include overall packets per second and bandwidth, as well as protocol-specific thresholds for TCP, UDP, ICMP and TCP SYN traffic.
For example, an operator can configure an alert or attack action when an IPv6 host exceeds an expected UDP packet rate or overall bandwidth threshold.
FastNetMon hostgroups can also contain IPv6 prefixes. This allows different groups of networks or customers to use different thresholds rather than applying a single DDoS threshold across the entire network.
That can be useful in environments where customer servers, infrastructure services and high-bandwidth systems have very different normal traffic profiles.
From an operational point of view, IPv6 therefore does not require a separate detection platform or a completely different detection model. IPv4 and IPv6 traffic can be monitored using the same FastNetMon deployment and the same types of traffic thresholds.
Mitigating IPv6 DDoS attacks
FastNetMon currently supports automatic IPv6 attack mitigation in blackhole mode.
When an IPv6 host is detected as being under attack and the relevant attack actions are enabled, FastNetMon can announce the attacked host as an IPv6 /128 over BGP.
Operators can configure the BGP community and next hop used for these IPv6 announcements. FastNetMon also supports IPv6-specific AS path configuration.
This allows the announcement to integrate with the operator's BGP blackhole policy, for example using an RTBH community understood by upstream or internal routers.
IPv6 blocking must be enabled explicitly:
sudo fcli set main enable_ban_ipv6 enable sudo fcli commit
FastNetMon Advanced 2.0.381, released in July 2026, also added support for manually announcing IPv6 BGP FlowSpec rules.
It is important to distinguish this from automatic IPv6 FlowSpec mitigation. FastNetMon can originate manually defined IPv6 FlowSpec announcements, but the detection logic that automatically generates selective IPv6 FlowSpec rules from an attack is not currently implemented.
Automatic IPv6 attack mitigation therefore remains based on blocking the attacked host rather than automatically constructing a selective FlowSpec filter.
IPv4 and IPv6 in the same FastNetMon deployment
For dual-stack networks, IPv6 does not require a separate FastNetMon installation.
IPv4 and IPv6 prefixes can be monitored by the same system, using the same traffic sources and operational tooling. Operators can inspect IPv6 traffic counters, configure thresholds for IPv6 hosts and prefixes, detect attacks and automatically trigger IPv6 BGP blackhole announcements.
The main requirement is to make sure IPv6 is included throughout the monitoring path: the network equipment needs to export IPv6 traffic information, the relevant IPv6 prefixes need to be configured in FastNetMon, and IPv6 mitigation needs to be configured if automatic blocking is required.
For configuration details and the latest information on supported IPv6 functionality, see the FastNetMon Advanced IPv6 support documentation.
