How do you detect IPv6 neighbor spoofing?
The IPv6 twin of ARP poisoning — how forged Neighbor Advertisements hijack your router’s address, the Windows commands that surface it, and why IPv4 stays clean the whole time.
You detect it by watching one binding: your router’s IPv6 address and the MAC it answers from. IPv6 has no ARP — devices map addresses to hardware using Neighbor Discovery, and it trusts whatever it hears. An attacker forges Neighbor Advertisements so your router’s fe80:: address points at their MAC. On Windows you surface it with Get-NetRoute and Get-NetNeighbor; catching it reliably means baselining that router MAC and alerting the moment it changes.
IPv4 looks perfect. That’s the point — the attacker only had to poison the half you weren’t watching.
What IPv6 neighbor spoofing actually is
IPv6 replaced ARP with Neighbor Discovery: to reach another device on the local link, your computer sends a Neighbor Solicitation and trusts the Neighbor Advertisement that comes back — the message that says “that address is at this MAC.” Like ARP, it has no authentication by default.
An attacker sends unsolicited, forged advertisements claiming your router’s link-local address (its fe80:: address) now lives at their MAC. Your IPv6 traffic detours through them. For the full mechanism, see how IPv6 neighbor spoofing works, its IPv4 twin ARP spoofing, and the broader man-in-the-middle family.
What the attack looks like
The poisoning leaves a small set of fingerprints in your device’s view of the network:
- Your router’s IPv6 MAC changed. The
fe80::router address that used to resolve to one MAC now resolves to another. This is the single strongest signal. - IPv4 looks totally fine. The tell is that only IPv6 is affected — general connectivity, and any IPv4 check, sees nothing wrong.
- One MAC, many IPv6 neighbors. A single hardware address shows up next to several IPv6 addresses in the neighbor cache — one machine claiming to be many.
- A stream of unsolicited advertisements. Neighbor Advertisements arriving when nothing asked for them, repeated often enough to keep overriding the real router binding.
- Occasional IPv6 hiccups. Not always present, but the tug-of-war between the real router and the attacker can cause brief stalls — easy to blame on “bad WiFi.”
How to check for it on Windows
Two quick commands show you the router’s IPv6 address and the MAC it currently answers from. Note the MAC, then re-check later — a change to a different valid MAC is the poisoning.
# 1. Find the router's IPv6 link-local address (the ::/0 default-route next hop) Get-NetRoute -AddressFamily IPv6 -DestinationPrefix ::/0 # 2. List IPv6 neighbors and find the router's fe80:: row. # Note its LinkLayerAddress (MAC) — that's the binding you're guarding. Get-NetNeighbor -AddressFamily IPv6 | Format-Table IPAddress, LinkLayerAddress, State # 3. Watch just the router entry: paste its fe80:: address in place of <router> Get-NetNeighbor -AddressFamily IPv6 -IPAddress <router> | Format-List IPAddress, LinkLayerAddress, State
A single snapshot is useful but blind to a poisoning that has already settled — the cache just shows the attacker’s MAC as “the router,” stable and wrong. Watching the binding over time is what turns a snapshot into detection.
Why this one slips past you
The attack is built to hide in the half of the network you don’t think about. Most people — and most quick checks — reason about IPv4. But Happy Eyeballs, the algorithm apps use to race IPv4 and IPv6, usually prefers IPv6 when it’s available. So the attacker poisons IPv6, wins the path your real traffic actually takes, and leaves IPv4 pristine as cover.
The other trap is false alarms. IPv6 hosts constantly rotate SLAAC privacy addresses, so a naive “did any IPv6 mapping change?” monitor screams all day. The fix is to anchor only on the router set: a reboot keeps the same MAC, and a real hardware swap changes the router address (a new-router event), so the one thing left that changes a stable router address’s MAC is poisoning.
Catching it automatically
WifiThreatWatch does this continuously. It learns your router’s IPv6 address from the default route, baselines the MAC that address answers from, and raises a verified alert the instant that binding flips to a different MAC — while deliberately ignoring the SLAAC privacy-address churn that fools naive checks. No commands to run, no table to re-read. Detection is free.
Go deeper: how we detect IPv6 neighbor spoofing · ARP spoofing (the IPv4 twin) · the threats library
IPv6 neighbor spoofing: quick answers
How do I know if my IPv6 neighbor cache is being poisoned?
The clearest sign is your router’s IPv6 link-local address (the fe80:: address) suddenly resolving to a different MAC than it normally does. On Windows you can note the router MAC with Get-NetNeighbor and re-check it later. Because the attack often leaves IPv4 completely clean, the tell is specifically in the IPv6 neighbor table, not in your general connectivity.
Can IPv6 Neighbor Discovery really be spoofed?
Yes. Neighbor Discovery replaces ARP in IPv6 and, like ARP, has no authentication by default — a host trusts whatever Neighbor Advertisement it receives. Public tools such as the THC-IPv6 suite send forged advertisements that bind the router’s address to the attacker’s MAC. SEND (Secure Neighbor Discovery) and RA Guard exist to counter this, but home routers almost never enable them.
Does turning off IPv6 stop this attack?
Disabling IPv6 removes this particular attack surface, but it is a blunt fix: many modern apps and services prefer or rely on IPv6, and turning it off can cause its own problems. It also does nothing about the IPv4 equivalent, ARP spoofing. Detecting the poisoning is a better answer than blinding yourself to half the network.
What does Get-NetNeighbor show?
Get-NetNeighbor prints your device’s IPv6 (and IPv4) neighbor cache: a list of neighbor addresses and the MAC addresses your device currently believes they belong to, plus each entry’s state (Reachable, Stale, and so on). It’s the IPv6 equivalent of “arp -a.” It’s useful for spotting a router address that has changed MAC — but it’s a point-in-time snapshot of a table an attacker may have already rewritten.
Is this the same as ARP spoofing?
It’s the direct IPv6 twin. ARP spoofing poisons the IPv4 IP-to-MAC mapping; IPv6 neighbor spoofing poisons the IPv6 address-to-MAC mapping via forged Neighbor Advertisements. The danger of the IPv6 version is that it can succeed while IPv4 looks perfectly healthy, and modern software often prefers the IPv6 path — so an IPv4-only check misses it entirely.