Preventing IPv6 Neighbor Discovery Attacks with MLD Snooping

IPv6 neighbor discovery (ND) is essential for address resolution and router advertisement, but it’s also a common attack vector. Spoofed NA/NS packets can lead to man-in-the-middle, DoS, or address theft. In my environment, I’ve seen attackers flood switches with fake neighbor solicitations to overload the ND cache or hijack traffic. Relying on host-based protections like ipv6 nd raguard isn’t enough when the attack hits the L2 layer. That’s where MLD snooping comes in—not just for multicast traffic control, but as a first line of defense against ND-based threats.

How MLD Snooping Mitigates ND Attacks

MLD snooping listens to Multicast Listener Discovery reports to learn which ports need IPv6 multicast traffic (like ff02::1 for all-nodes or ff02::2 for all-routers). Without it, switches flood IPv6 multicast to all ports, just like unknown unicast. Attackers exploit this by sending spoofed ND messages to the all-nodes multicast address, forcing every port to process useless traffic. When MLD snooping is enabled, the switch builds a multicast forwarding table and only sends relevant traffic to interested ports. This stops ND floods from reaching unintended hosts, reducing the attack surface significantly.

Enabling MLD Snooping on Common Switch Platforms

On Linux bridges, you enable MLD snooping via sysfs:

echo 1 > /sys/class/net/br0/bridge/mld_snooping
echo 1 > /sys/class/net/br0/bridge/mld_snooping.querier

On Cisco switches, it’s interface-based:

interface range gigabitEthernet 0/1 - 24
 ipv6 mld snooping
 ipv6 mld snooping v2

For Juniper EX series:

set protocols mld-snooping vlan all flood-unknown-reports disable

Always verify with show ipv6 mld snooping or bridge mld show to confirm the snooping table is populating correctly.

Combining MLD Snooping with RA Guard for Layered Defense

MLD snooping stops the flood, but doesn’t validate ND message content. I pair it with IPv6 RA guard on the switch to drop unauthorized router advertisements and redirects. On Cisco, that’s:

ipv6 nd raguard policy deny-all
 device-role host
interface gigabitEthernet 0/1
 ipv6 nd raguard attach-policy deny-all

This combo ensures only legitimate ND traffic flows, and only to ports that actually need it. As I mentioned before in my post about Linux bridge MAC ageing, L2 hardening is often overlooked until an incident occurs—don’t wait for ND-based slowness or hijacking to act.

Monitoring and Tuning Tips

Watch for high MLD report rates or frequent querier elections, which can indicate misconfiguration or probing. On Linux, check:

cat /sys/class/net/br0/bridge/mld_snooping.queries
cat /sys/class/net/br0/bridge/mld_snooping.reports

If you see constant floods from a single port, investigate the host—it might be compromised or misconfigured. Tune the last member query interval if you have leafy multicast workloads, but keep the default (1 second) for most edge networks to maintain fast leave detection.

Why This Matters for IPv6 Security

IPv6’s reliance on multicast for ND makes L2 controls critical. Unlike IPv4 ARP, which is unicast-heavy, IPv6 ND uses multicast by design, making flooding more effective. MLD snooping isn’t just about optimizing multicast streams—it’s a foundational security control. In public-sector and e-commerce setups I manage, enabling it reduced switch CPU load during ND scans and stopped several attempted MITM attempts before they reached hosts.

Conclusion

MLD snooping is a simple, effective way to contain IPv6 neighbor discovery attacks at the switch level. Enable it, combine it with RA guard, monitor the counters, and treat it as part of your IPv6 baseline—not an afterthought. It won’t stop every ND-based threat, but it removes the easiest path for attackers to flood or spoof at L2.

Cover image: Unknown · CC0 (Openverse / kamu malı) · https://www.rawpixel.com/image/6038427/photo-image-public-domain-technology-line