ARP and IPv6 Neighbor Discovery Explained: Spoofing and Defenses

ARP (RFC 826, November 1982) and IPv6 Neighbor Discovery (RFC 4861, September 2007) answer one question on every local network: which hardware address owns this IP address? Every host and router on Ethernet or Wi-Fi depends on them. Neither authenticates its answers, so any device on the link can lie, and defence lives mostly in switches and host settings.

An IP packet bound for the default gateway still needs the gateway's 48 bit hardware address before any frame can be built. ARP fills that gap for IPv4. Neighbor Discovery, often shortened to NDP or ND, fills it for IPv6 and also tells hosts which routers exist, which prefixes are on the link, and whether a neighbour is still reachable. This post covers both protocols on the wire, why their trust model allows spoofing and rogue routers, what SEcure Neighbor Discovery (SEND) tried to fix, switch side defences in vendor neutral terms, and the commands a defender runs on Linux and Windows. Everything is checked against the RFCs and the official Linux and Microsoft documentation.

Key takeaways

• ARP is defined by RFC 826 (November 1982), an Internet Standard updated by RFC 5227 (July 2008, address conflict detection) and RFC 5494 (April 2009, IANA rules). It runs directly over the link layer with EtherType 0x0806 and has two everyday opcodes: 1 for request, 2 for reply.
• IPv6 Neighbor Discovery is defined by RFC 4861 (September 2007), which obsoletes RFC 2461 (December 1998), itself the successor to RFC 1970 (August 1996). It runs inside ICMPv6 and uses five message types: Router Solicitation (133), Router Advertisement (134), Neighbor Solicitation (135), Neighbor Advertisement (136) and Redirect (137).
• RFC 826's receive algorithm updates an existing cache entry from any ARP packet before it even looks at the opcode. RFC 4861 states plainly that the protocol "does not allow hosts to verify" that the sender of a Neighbor Advertisement owns the address. That is the root of ARP spoofing, neighbour cache poisoning and rogue router advertisements.
• NDP's one built in protection is the Hop Limit 255 check, which proves a message came from the local link but not who sent it.
• SEND (RFC 3971, March 2005) adds signatures, Cryptographically Generated Addresses, timestamps and nonces. RFC 6104 (February 2011) recorded that SEND was "not yet widely used".
• Practical defences live on the switch: DHCP snooping, ARP inspection, RA Guard (RFC 6105, hardened by RFC 7113), source address validation (SAVI) and 802.1X.
• ip neigh show on Linux and Get-NetNeighbor on Windows print the caches. Encryption above the link (TLS, SSH, IPsec) keeps a poisoned cache from becoming a data breach.

What ARP and Neighbor Discovery are for, their layer and their standards

The problem both protocols solve

IP addresses are logical. Ethernet and Wi-Fi deliver frames to hardware addresses, the 48 bit values usually called MAC addresses. When a host wants to send an IP packet to a neighbour on the same link, or to the router that will forward it off the link, it must first learn the neighbour's hardware address. Without that mapping, no frame can be built and nothing leaves the network card.

RFC 826 frames the problem in its original 1982 terms: converting "network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware". The design is general. The hardware type and protocol type fields let the same packet format resolve other protocol addresses on other link types, which is why ARP outlived the 10 Mbit Ethernet it was written for.

IPv6 took a different route. Rather than a separate link layer protocol, RFC 4861 places address resolution inside ICMPv6 and bundles it with several jobs that IPv4 spreads across ARP, ICMP Router Discovery and ICMP Redirect. RFC 3971 summarises the full list of NDP functions as router discovery, address autoconfiguration, address resolution, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD) and redirection.

Where they sit in the stack

RFC 4862 (September 2007), IPv6 Stateless Address Autoconfiguration (SLAAC), sits beside RFC 4861. It defines how a host builds its own addresses from the prefixes it hears in Router Advertisements and how Duplicate Address Detection uses Neighbor Solicitations to check them. The two documents are usually read together, and both were updated in June 2025 by RFC 9762, which lets Router Advertisements signal that DHCPv6 prefix delegation is available.

Why every LAN depends on them

Every packet that leaves a host on Ethernet or Wi-Fi needs a resolved next hop. If ARP or ND answers wrongly, the packet goes to the wrong machine, and DNS, TLS, SSH and everything else above it inherit that mistake. Our post on how attackers intercept network traffic on copper, fiber and Wi-Fi covers the physical side of interception; this post covers the protocol logic that lets a device on the same segment redirect traffic without touching a cable.

How ARP works on the wire

The ARP packet

RFC 826 defines a single packet format used for both requests and replies. For Ethernet and IPv4 the hardware address length is 6 bytes and the protocol address length is 4, giving a 28 byte ARP payload inside the Ethernet frame.

Notice what is not there: no sequence number, no transaction identifier, no timestamp, no signature. The packet is a bare claim that "this IP address lives at this hardware address".

One resolution, step by step

Host A (10.0.0.5, MAC aa)                 Host B (10.0.0.9, MAC bb)
   |                                                |
   |  ARP REQUEST, broadcast to ff:ff:ff:ff:ff:ff   |
   |  sha=aa spa=10.0.0.5 tha=0 tpa=10.0.0.9        |
   |----------------------------------------------->|  every host on the
   |                                                |  segment receives it
   |                                                |
   |        B is the target: it records A's mapping |
   |        then swaps fields and sets op=REPLY     |
   |                                                |
   |  ARP REPLY, unicast to aa                      |
   |  sha=bb spa=10.0.0.9 tha=aa tpa=10.0.0.5       |
   |<-----------------------------------------------|
   |                                                |
   |  A caches 10.0.0.9 -> bb and sends the queued  |
   |  IP packet in an Ethernet frame addressed to bb|

The receive algorithm in RFC 826 is short, and the order of its steps matters for security. When an ARP packet arrives, the receiver checks that it speaks the hardware and protocol types. Then, if the sender's protocol address is already in its table, it updates the stored hardware address with the one in the packet and sets a merge flag. Only after that does it check whether it is the target, add a new entry if needed, and finally look at the opcode. RFC 826 even marks the moment with "(NOW look at the opcode!!)". The stated reasoning is that communication is usually two way, so if A asks for B, B will probably want to talk to A. The document also says that when an entry exists, "the new hardware address supersedes the old one". In 1982 that was a sensible efficiency on a trusted cable. It is also the precise reason a forged ARP packet can overwrite a good cache entry.

Probes, announcements and gratuitous ARP (RFC 5227)

RFC 5227, IPv4 Address Conflict Detection, does not change the packet format or the RFC 826 rules. It adds a procedure built from two specific forms of ARP request:

• An ARP Probe is a broadcast request with the sender IP address set to all zeroes and the target IP address set to the address the host hopes to use. The zero sender address is required "to avoid polluting ARP caches" in other hosts if the address turns out to be taken.
• An ARP Announcement is the same broadcast request with both sender and target IP fields set to the address now in use. It tells the link "this is the address I am now using". RFC 5227 notes that the traditional "gratuitous ARP" is the same packet, and that gratuitous ARP alone does not provide effective duplicate detection.

RFC 5227 fixes the timing as constants that are "not intended to be modifiable":

A host using an address must react to a conflicting ARP packet in one of three ways: give up the address; defend it once with a single announcement, giving up if another conflict arrives within DEFEND_INTERVAL; or, for devices such as a default router that must keep a fixed address, defend indefinitely while logging the source Ethernet address and informing an administrator. That last rule is the closest thing ARP has to built in detection.

How IPv6 Neighbor Discovery works on the wire

The five message types

Every ND message is an ICMPv6 message sent with an IPv6 Hop Limit of 255. The receiver must check that value and discard anything lower. Because routers decrement the hop limit when forwarding, a 255 proves the packet originated on the local link.

The IANA ICMPv6 registry lists types 133 to 137 against RFC 4861, and types 148 and 149 (Certification Path Solicitation and Advertisement) against RFC 3971 for SEND.

Router Advertisement fields that matter for security

Every field in that table directly shapes how hosts on the link route and configure themselves, which is why a forged RA is so much more powerful than a forged ARP reply.

Neighbor Advertisement flags

The O flag is the IPv6 equivalent of RFC 826's "supersedes the old one". RFC 4861 says it should be set in unsolicited advertisements, so a node that changes its hardware address can tell its neighbours.

The ND options

Address resolution, step by step

Host A (2001:db8::5)                          Host B (2001:db8::9)
   |                                                |
   |  A creates a Neighbor Cache entry: INCOMPLETE  |
   |                                                |
   |  ICMPv6 NS (type 135), Hop Limit 255           |
   |  dst = solicited-node multicast of B           |
   |       ff02::1:ff00:9                           |
   |  target = 2001:db8::9, option: A's MAC         |
   |----------------------------------------------->|  only nodes listening
   |                                                |  on that group get it
   |                                                |
   |  ICMPv6 NA (type 136), Hop Limit 255           |
   |  flags S=1 O=1, option: B's MAC                |
   |<-----------------------------------------------|
   |                                                |
   |  A's entry moves INCOMPLETE -> REACHABLE       |

The solicited-node multicast address comes from RFC 4291 (February 2006): ff02::1:ffXX:XXXX, built from the low-order 24 bits of the target address. Using multicast rather than broadcast means only a handful of hosts on the link process each solicitation, an efficiency gain over ARP that does nothing for security, because any node can join any multicast group.

Router discovery and SLAAC

A host coming up sends Router Solicitations (RFC 4861 allows up to three, MAX_RTR_SOLICITATIONS, spaced RTR_SOLICITATION_INTERVAL of 4 seconds apart). Routers reply with Router Advertisements and also send them periodically. From an RA the host learns its default routers, the on-link prefixes, the link MTU, and whether to use DHCPv6. Under RFC 4862 it then forms addresses from the advertised prefixes. Temporary, privacy oriented addresses are specified in RFC 8981 (February 2021), which obsoletes RFC 4941.

Duplicate Address Detection

Before using a new address, an IPv6 host marks it tentative and sends Neighbor Solicitations for it from the unspecified address. RFC 4862 sets the default number of these, DupAddrDetectTransmits, to 1, with no follow up retransmission. If any node answers, or another host is probing the same address at the same moment, the address is a duplicate and is not used. Linux exposes the same knob as the dad_transmits sysctl, documented with a default of 1.

Neighbor Unreachability Detection

Each IPv6 Neighbor Cache entry moves through the states that RFC 4861 defines. Linux uses the same names for both IPv4 and IPv6 entries, and Windows reports a similar set through Get-NetNeighbor.

RFC 4861's default REACHABLE_TIME is 30,000 milliseconds, randomised between 0.5 and 1.5 times that value, and its default RETRANS_TIMER is 1,000 milliseconds. The Linux arp(7) page documents the matching base_reachable_time default of 30 seconds and delay_first_probe_time of 5 seconds.

Two RFC 4861 behaviours matter for security: an NS carrying a source link-layer address option creates or updates a cache entry for its sender, and an unsolicited NA with the O flag overwrites a cached hardware address. Both speed convergence, and both let one unauthenticated message change where traffic goes.

Redirect

A router that forwards a packet back out of the interface it arrived on can send the host a Redirect saying a better first hop exists, or that the destination is actually on-link. RFC 4861 limits acceptance: a host accepts a Redirect only from the router it is currently using for that destination, and only with a Hop Limit of 255. That is a real improvement over IPv4, where RFC 4861 notes that off-link senders could send both ICMP Redirects and Router Advertisements.

Gratuitous Neighbor Discovery (RFC 9131)

RFC 9131 (October 2021) lets routers create a STALE cache entry from an unsolicited NA for a new address, and recommends hosts send one when they assign a new IPv6 address, to avoid losing the first reply. Linux implements the router side as accept_untracked_na, default 0. Like many ND updates, it trades a little more trust for a little less latency.

Versions and history

What is deployed in practice: ARP as RFC 826 describes it, with RFC 5227 conflict detection in many host stacks, and ND as RFC 4861 describes it with SLAAC from RFC 4862. Nothing in either protocol has been deprecated in a way that changes the trust model. The updates refine timing, multi-prefix behaviour and IANA rules. The one cryptographic layer, SEND, is a separate optional protocol.

Security properties: what ARP and NDP guarantee and what they do not

RFC 4861's own Security Considerations section groups the main vulnerabilities into three categories: denial of service, address spoofing and router spoofing. It also states that the protocol "contains no mechanism to determine which neighbors are authorized to send a particular type of message". RFC 5227 is equally direct about ARP: "it is easy for a host to answer all ARP Requests with Replies giving its own hardware address, thereby claiming ownership of every address on the network."

Why both protocols trust any reply on the link

Both designs assume the attached devices are trusted, and both favour fast convergence over verification. ARP, written for 1982 Ethernet with no infrastructure to check claims against, lets newer information replace older on every packet, request or reply, before the opcode is checked. A cache entry is only as trustworthy as the last packet that mentioned that IP address.

ND improved several things: it ignores off-link senders, it limits Redirects to the current router, and it moves solicitations to multicast. But it inherited the same core assumption. The original specifications called for IPsec to protect ND, and RFC 3971 explains why that never worked in practice: IKE cannot bootstrap security associations for the very messages needed to reach a neighbour in the first place, and manually keyed associations do not scale. RFC 4861 repeats the point and leaves cryptographic protection to SEND. Without SEND, a Neighbor Advertisement is a claim, and a Router Advertisement is an instruction any neighbour can issue.

The link layer adds its own trust problem. RFC 4861 notes that many link layers allow "originating packets with somebody else's source MAC address to confuse, e.g., Ethernet switches". Even SEND does not bind the hardware address in the frame to the IPv6 address in the signed message, which RFC 3971 calls out as a threat it does not cover.

Weakness classes, described as concepts

These are described as what goes wrong and why the design allows it. Each needs only an ordinary device on the same segment, which is why the useful defences control what an attached device can send.

Address spoofing and cache poisoning

A device on the link sends ARP packets, or IPv6 Neighbor Advertisements with the O flag set, that claim another host's IP address maps to its own hardware address. Receivers update their caches, because RFC 826 and RFC 4861 both say a newer mapping replaces an older one. Traffic meant for the victim, very often the default gateway, now arrives at the claiming device. RFC 4861 describes exactly this: a node can send an NA with "a victim's IP address and its own link-layer address" and force the sender "to forward all of the victim's traffic to itself".

The same mechanism used the other way round is a flooding attack. RFC 4861 also describes advertising one's own IP address with a victim's link-layer address so the victim receives traffic it never asked for.

The result is an on-path position on the local segment. What that position allows depends entirely on the protocols above: unencrypted traffic can be read and changed, while TLS, SSH or IPsec traffic can be dropped or delayed but not read, provided certificates and host keys are checked properly.

Rogue Router Advertisements

A device sends RAs claiming to be a default router, or advertising prefixes, DNS settings or a hop limit that hosts will adopt. RFC 4861 describes the extreme case: a node advertises itself as a default router and sends forged RAs, apparently from each legitimate router, with Router Lifetime set to zero and prefix lifetimes set to zero, so that "all packets, for both on-link and off-link destinations" go to the rogue router. It adds that NUD will not notice, because the rogue router answers reachability probes correctly.

This matters even where nobody thinks they run IPv6, because hosts that accept RAs will configure IPv6 from them. RFC 6104 is worth reading for the less dramatic side. It reported in February 2011 that malicious rogue RAs were rarely documented while "accidental rogue RAs are very commonplace": a router interface misconfigured by an administrator, or a user's laptop with a connection sharing feature turned on that starts advertising itself as a gateway. A defence that stops the malicious case also stops the accidental one, which is a strong operational argument on its own.

Redirect abuse

RFC 4861 limits Redirects to the router currently in use, but a device that first wins the router role through a rogue RA can then steer individual destinations. On IPv4, Linux documents accept_redirects as on for hosts and off for routers by default. Our ICMP post on what to allow and block covers the IPv4 side in detail.

Duplicate Address Detection denial of service

DAD asks the link whether an address is in use and trusts any answer. RFC 4861 notes that any host can prevent another from configuring an address, because the protocol cannot verify that the responder actually owns it. RFC 3756 lists this as its own threat class. The IPv4 equivalent follows from RFC 5227: a host that gives up its address on conflict can be pushed off it, and RFC 5227 warns that this "potentially makes it easier for malicious attackers on the same link to hijack TCP connections".

Neighbour cache exhaustion

RFC 6583 (March 2012) describes a problem specific to IPv6. A standard /64 subnet covers an enormous number of addresses, almost all unused. A router asked to deliver packets to many nonexistent addresses on that subnet creates an INCOMPLETE cache entry for each and solicits for each. Simplistic implementations can fill their tables, and RFC 6583 says that as a result "new devices may not be able to join a network" and existing flows can be interrupted. The traffic can come from off the link, which makes this the one ND weakness that a remote party can reach. Linux bounds the table with gc_thresh1, gc_thresh2 and gc_thresh3, documented with defaults of 128, 512 and 1024 entries.

Filter evasion with extension headers and fragments

Switch side RA filtering only works if the switch can recognise an RA. RFC 7113 records that some implementations looked only at the first Next Header field and could be bypassed by placing an IPv6 extension header in front of the ICMPv6 message, and that splitting an RA across fragments defeated "all existing implementations" at the time, because the switch could not see the ICMPv6 type in any single fragment. The fix came in two parts. RFC 6980 (August 2013) requires nodes to silently ignore NS, NA, RS, RA and Redirect messages carried in fragmented packets, so fragmented ND has no effect even if it gets through. RFC 7113 tells RA Guard implementations to parse the entire header chain, drop first fragments that do not contain the full chain, and drop packets with unrecognised next header values by default.

RFC 7113 adds that the same techniques could evade passive ND monitoring tools, so any sensor you rely on needs the same full header chain parsing.

SEND (RFC 3971): what it tried to fix and why it is rarely deployed

SEcure Neighbor Discovery, published in March 2005 alongside Cryptographically Generated Addresses (RFC 3972), is the IETF's answer to the trust problem. It adds four mechanisms:

On paper this closes address spoofing, rogue routers, replay and DAD interference. RFC 3971 is frank about the limits it leaves: no confidentiality, no binding between the frame's source MAC and the signed IPv6 address, and no protection for the Multicast Listener Discovery messages a node uses to join its solicited-node group.

Why did it not take off? RFC 6104, six years later, said SEND was "not yet widely used", partly because "there are very few implementations". It cited a bootstrapping problem (a host validating a router usually needs that router to fetch certificate or time data), routers not wanting autogenerated addresses, user managed campus hosts that are hard to provision with trust anchors, and sensor class devices that may never implement it. RFC 6105 adds that "it may take time until SEND is ubiquitous". The crypto has also aged: SEND fixed on RSA with SHA-1 to avoid negotiation.

So most networks protect ND the RA Guard way, deciding on the switch which ports may speak for routers. RFC 6105 calls RA Guard complementary to SEND and notes it can simplify SEND, since only the switch and routers then need certificates.

Switch side defences, described vendor neutrally

These features exist under different names on different equipment. The descriptions below follow the IETF documents where one exists, and describe the common concept where none does. Check your own equipment's documentation for the exact behaviour.

DHCP snooping and binding tables

The switch watches DHCP exchanges, trusts DHCP server messages only on ports configured as facing a legitimate server, and records which IP address was leased to which MAC address on which port. RFC 7610 (August 2015), DHCPv6-Shield, describes the IPv6 version of the same idea and notes that "a similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping')". RFC 7513 (May 2015) standardises how a Source Address Validation Improvement (SAVI) device builds those bindings from DHCPv4 and DHCPv6 and then uses them "to filter packets with forged source IP addresses". The binding table is the foundation for the next two features. Our DHCP explainer covers the lease protocol itself.

ARP inspection

The switch feature usually called dynamic ARP inspection checks the sender MAC and IP fields of each ARP packet on an untrusted port against the binding table and drops mismatches, so a host can only claim the address it was leased. Static devices need static bindings; uplinks are usually marked trusted. No RFC defines this feature, so your switch documentation is the authority, though RFC 7513's data snooping process covers related ground using ARP replies and Neighbor Advertisements.

RA Guard (RFC 6105 and RFC 7113)

RA Guard drops Router Advertisements arriving on ports where no router should be. RFC 6105 describes two forms:

• Stateless RA Guard decides on each RA using information in the frame (sender MAC, port, source IP, advertised prefixes) and switch configuration (allowed ports, allowed sources, allowed prefix list, router priority). The simplest version marks one port as the router port and blocks RAs on all others.
• Stateful RA Guard learns legitimate routers during a manually started LEARNING period, then moves each port to FORWARDING or BLOCKING. RFC 6105 stresses that the learning state must only be entered intentionally and that learned routers should be verified. A SEND based variant validates RAs against certificates on behalf of hosts.

RFC 6105 also states the key applicability limit: RA Guard only works where "all messages between IPv6 end-devices traverse the controlled L2 networking devices". On shared media, or between two Wi-Fi clients that can reach each other directly, it cannot help. RFC 7113 adds the hardening rules covered above: parse the whole header chain, drop incomplete first fragments, default to dropping unknown next headers, and pass packets that cannot be RAs anyway (non link-local source, or hop limit other than 255).

Source address validation (SAVI)

RFC 7039 (October 2013) is the SAVI framework: switch features that stop "nodes attached to the same IP link from spoofing each other's IP addresses". RFC 6620 (May 2012), First-Come, First-Served SAVI, binds an IPv6 address to the first port that uses it, which suits SLAAC networks with no DHCP to snoop. RFC 7513 covers DHCP assigned addresses. Together they are the IPv6 counterpart to binding based ARP inspection, applied to data packets as well as ND.

Port authentication with IEEE 802.1X

IEEE 802.1X, Port-Based Network Access Control (the 2020 edition, with a revision project listed on the IEEE 802.1 site), guards "against transmission and reception by unidentified or unauthorized parties". It does not inspect ARP or ND, but it makes a device authenticate before it can send anything, which narrows who can attempt spoofing and makes the source traceable. Our post on Wi-Fi certificates versus shared passwords with 802.1X covers the wireless case.

Segmentation, isolation and static entries

A device can only spoof neighbours on its own link, so separate VLANs for guests, IoT devices, servers and management cut the reach of any one compromised device. Wireless client isolation removes direct neighbour access. Static entries for critical gateways (nud permanent in ip neigh add on Linux) work but are hard to maintain, so keep them for small fixed segments.

Secure configuration, with defender side check commands

Only run these against systems you own or are authorised to administer. Every command below is read only unless marked otherwise, and comes from the cited official documentation.

Linux: view the ARP and neighbour caches

From the ip-neighbour(8) man page and the ip(8) man page, where -4 and -6 select the address family and -s adds statistics:

# Whole neighbour table (IPv4 ARP entries and IPv6 ND entries)
ip neigh show

# IPv4 only, then IPv6 only
ip -4 neigh show
ip -6 neigh show

# Entries in a given NUD state: failed, stale, permanent and so on
ip neigh show nud failed
ip neigh show nud permanent

# Every state, including noarp entries that are hidden by default
ip neigh show nud all

# Look up the entry for one address on one interface
ip neigh get 10.0.1.10 dev eth0

# More detail, including timers
ip -s neigh show

The man page explains that without a nud filter, ip lists every entry except those in the none and noarp states, and that permanent entries can only be removed administratively. The older net-tools arp command, documented in arp(8), still works on many systems: arp -n prints the IPv4 table with numeric addresses, and the kernel exposes the same table at /proc/net/arp.

What to look for:

• Two IP addresses with the same hardware address. A router legitimately answers for itself only. If your default gateway's IP address and another host's IP address resolve to the same MAC, investigate. Proxy ARP and some load balancers do this on purpose, so confirm against your own network design.
• A gateway MAC that changed without a known hardware swap or failover. Keep a record of the expected gateway MAC per segment and compare.
• Many entries in incomplete or failed on a router or a busy host, which can mean scanning of unused addresses or the cache pressure that RFC 6583 describes.

Linux: check IPv6 duplicate address detection results

From the ip-address(8) man page:

# IPv6 addresses that failed duplicate address detection
ip -6 addr show dadfailed

# IPv6 addresses still being checked
ip -6 addr show tentative

A dadfailed address means another node answered for it. That can be an honest duplicate, a misconfigured static address, or the DAD interference described above.

Linux: review the ARP and ND sysctls

From the kernel's IP sysctl documentation and the sysctl(8) man page. The --pattern form appears in the sysctl(8) examples.

# All ARP related settings for every interface
sysctl -a --pattern 'net.ipv4.conf.*.arp'

# Individual values (replace eth0 with your interface)
sysctl net.ipv4.conf.eth0.arp_ignore
sysctl net.ipv4.conf.eth0.arp_announce
sysctl net.ipv4.conf.eth0.arp_accept
sysctl net.ipv4.conf.eth0.drop_gratuitous_arp

# IPv6 router advertisement and neighbour handling
sysctl net.ipv6.conf.eth0.accept_ra
sysctl net.ipv6.conf.eth0.accept_redirects
sysctl net.ipv6.conf.eth0.drop_unsolicited_na
sysctl net.ipv6.conf.eth0.accept_untracked_na
sysctl net.ipv6.conf.eth0.dad_transmits

# Neighbour table limits
sysctl net.ipv4.neigh.default.gc_thresh3

What the kernel documentation says each one does:

On a multi-homed server, arp_ignore=1 and arp_announce=2 stop the host answering ARP on the wrong interface. On a statically addressed server, accept_ra=0 removes the rogue RA risk for that host, at the cost of ignoring legitimate RAs too. drop_gratuitous_arp and drop_unsolicited_na can break failover that relies on announcements, and the kernel documentation frames both for networks with a known good proxy, so test first. Persist changes through sysctl configuration files and configuration management.

Windows: view the neighbour cache and router discovery settings

From the Microsoft Learn pages for Get-NetNeighbor, Get-NetIPInterface and Set-NetIPInterface. Microsoft's documentation notes that in IPv4 the neighbour cache "is commonly known as the Address Resolution Protocol (ARP) cache".

# All neighbour cache entries, IPv4 and IPv6
Get-NetNeighbor

# Every property of each entry
Get-NetNeighbor | Format-List -Property *

# IPv6 entries only
Get-NetNeighbor -AddressFamily IPv6

# Adapters with reachable neighbours
Get-NetNeighbor -State Reachable | Get-NetAdapter

# IPv6 interface settings, including RouterDiscovery and Advertising
Get-NetIPInterface -AddressFamily IPv6 | Format-Table InterfaceAlias, RouterDiscovery, Advertising

Microsoft documents the State values as Unreachable, Incomplete, Probe, Delay, Stale, Reachable and Permanent, and notes that an all zero link-layer address means the neighbour is unreachable. Set-NetIPInterface accepts -RouterDiscovery values of Disabled, Enabled and ControlledByDHCP, and documents -Advertising (whether the interface sends Router Advertisements) with a default of Disabled. A Windows host that unexpectedly shows Advertising enabled on an IPv6 interface is a candidate source of the accidental rogue RAs that RFC 6104 describes.

Detecting address conflicts (RFC 5227)

RFC 5227 asks hosts that defend an address indefinitely to "log useful information such as source Ethernet address from the ARP packet, and inform an administrator". Check the host's system log for any conflict messages your operating system records, ip -6 addr show dadfailed on Linux, and above all the switch's counters for ARP inspection, RA Guard and DHCP snooping drops. A spike in drops on one access port is the clearest signal that something there is claiming addresses it does not own.

When to use which defence

There is no alternative protocol to ARP or ND for address resolution on Ethernet and Wi-Fi; every IP host uses them. The real choice is which protections to layer on top.

The last row is the one that keeps the others honest. Switch features shrink the chance of a poisoned cache; strong encryption with real authentication makes a poisoned cache far less useful.

Common mistakes

• Assuming IPv6 is off because nobody configured it. Hosts commonly ship with IPv6 enabled; Linux, for example, accepts RAs by default when forwarding is off. With no real IPv6 router, a rogue RA faces no competition. Turn on RA Guard even on IPv4 only access networks.
• Enabling ARP inspection without bindings for static devices. Printers, servers and network appliances with static addresses have no DHCP lease, so they get cut off unless static bindings exist.
• Trusting every uplink without thinking. Marking all inter-switch links trusted is normal, but a port that leads to an unmanaged switch or a desk hub is an access port, not an uplink.
• Running RA Guard firmware that does not follow RFC 7113. Ask the vendor whether the implementation parses the full header chain and drops incomplete first fragments. If it does not, it can be bypassed.
• Treating gratuitous ARP as conflict detection. RFC 5227 is explicit that a single gratuitous ARP does not provide effective duplicate detection; probing does.
• Disabling gratuitous ARP or unsolicited NA handling everywhere. High availability pairs and virtual IP failover rely on these announcements. Use switch side validation instead of blanket host side drops.
• Relying on RA Guard on Wi-Fi without client isolation. RFC 6105 says RA Guard does not apply where devices can communicate directly without passing through the filtering device.
• Forgetting the neighbour cache limits on routers serving large IPv6 subnets. RFC 6583 shows how unused /64 address space can exhaust a simplistic implementation. Review the router's ND rate limits and table sizes.
• Thinking HTTPS makes ARP spoofing irrelevant. It makes it far less damaging, but a redirected host can still be denied service, and any plaintext protocol, legacy management interface or client that ignores certificate errors remains exposed.

FAQ

What is the difference between ARP and NDP?

ARP resolves IPv4 addresses to hardware addresses using its own link layer packet (EtherType 0x0806). NDP does the same for IPv6 using ICMPv6 messages, and also handles router discovery, prefix discovery, duplicate address detection, reachability tracking and redirects. NDP uses multicast instead of broadcast and rejects messages that did not originate on the local link.

What port does ARP use?

None. ARP is not carried in TCP or UDP, so it has no ports. It sits directly on the link layer with EtherType 0x0806. NDP has no ports either; it uses ICMPv6 message types 133 to 137.

Is ARP encrypted or authenticated?

No. RFC 826 has no authentication, integrity or encryption, and RFC 5227 notes how easy it is for a host to claim every address on the network. IPv6 ND is also unauthenticated unless SEND (RFC 3971) is deployed, and even SEND does not encrypt.

What is ARP spoofing?

ARP spoofing, or cache poisoning, is a device on the local network claiming another host's IP address, often the gateway's, for its own hardware address. Because RFC 826 lets newer information replace older, neighbours send traffic to the wrong device. The IPv6 equivalent uses forged Neighbor Advertisements.

How do I see my ARP table?

On Linux, run ip neigh show (or ip -4 neigh show for IPv4 only). On Windows, run Get-NetNeighbor in PowerShell. Both show the IP address, the hardware address and the entry's state.

What is a rogue router advertisement?

A Router Advertisement sent by a device that should not be acting as a router. Hosts that accept it may add a new default gateway, configure addresses from a wrong prefix, or pick up other settings. RFC 6104 found accidental rogue RAs, such as a laptop sharing its connection, far more common than malicious ones. RA Guard on access switches blocks both.

What is gratuitous ARP?

An unrequested ARP packet a host sends about its own address, which RFC 5227 calls an ARP Announcement. Failover systems use it to move a shared IP address; because it can also be abused, validate it on the switch.

Is SEND still used?

Rarely. RFC 6104 recorded that SEND was "not yet widely used" because few implementations existed, and RFC 6105 pointed to the difficulty of provisioning trust anchors at scale. Most networks rely on RA Guard, ARP inspection and SAVI on switches instead.

Does 802.1X stop ARP spoofing?

Not by itself. IEEE 802.1X makes devices authenticate before they can use a port, which limits who can be on the link and makes misbehaviour traceable, but an authenticated device can still send false ARP or ND messages. Combine it with ARP inspection, RA Guard and segmentation.

Where Safeguard fits

Safeguard does not inspect, filter or block ARP or Neighbor Discovery traffic; those defences belong in your switches and host configuration.

Where Safeguard helps is the software that implements and depends on these protocols. Router advertisement daemons, DHCP clients and servers, ND proxy daemons and the network libraries inside container images all appear in your dependency graph. Safeguard's software composition analysis, generally available, builds a full transitive inventory of those components, and SBOM generation and analysis, also generally available, records them in SPDX and CycloneDX so you can answer "which images ship this daemon at this version?" quickly. Vulnerability management with EPSS and CISA KEV enrichment, plus reachability analysis, both generally available, ranks which findings in those components matter first. Container visibility and scanning, generally available as part of ESSCM, covers the base images where these packages usually arrive. The honest limit is the kernel: the ARP and ND code in an operating system kernel is fixed by your OS vendor and a reboot or live patch, not by a dependency upgrade.

Fix it without waiting for upstream

Weaknesses in address resolution usually surface as bugs in a kernel network stack or in user space daemons such as router advertisement servers, DHCP clients and ND proxies. The kernel part needs your operating system vendor; the daemons and libraries you ship inside your own images are where the steps below apply.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

This demo sets up the Safeguard runner on your own machine, approves it with its device code, and then runs a scan from the terminal. The same flow lets you scan a container image or repository that bundles a router advertisement daemon, DHCP client or other network component, and see every version it carries without uploading your source anywhere first.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same approve each step flow applies when the component to bump is a networking package pinned in your manifest or base image.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects or images include a particular daemon or library version, and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• RFC 826: An Ethernet Address Resolution Protocol, November 1982
• RFC 5227: IPv4 Address Conflict Detection, July 2008
• RFC 5494: IANA Allocation Guidelines for the Address Resolution Protocol (ARP), April 2009
• RFC 4861: Neighbor Discovery for IP version 6 (IPv6), September 2007
• RFC 4862: IPv6 Stateless Address Autoconfiguration, September 2007
• RFC 4291: IP Version 6 Addressing Architecture, February 2006
• RFC 1970: Neighbor Discovery for IP Version 6, August 1996
• RFC 2461: Neighbor Discovery for IP Version 6, December 1998
• RFC 3756: IPv6 Neighbor Discovery Trust Models and Threats, May 2004
• RFC 3971: SEcure Neighbor Discovery (SEND), March 2005
• RFC 3972: Cryptographically Generated Addresses (CGA), March 2005
• RFC 6494: Certificate Profile and Certificate Management for SEND, February 2012
• RFC 6104: Rogue IPv6 Router Advertisement Problem Statement, February 2011
• RFC 6105: IPv6 Router Advertisement Guard, February 2011
• RFC 7113: Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard), February 2014
• RFC 6980: Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery, August 2013
• RFC 6583: Operational Neighbor Discovery Problems, March 2012
• RFC 9131: Gratuitous Neighbor Discovery, October 2021
• RFC 9762: Using Router Advertisements to Signal the Availability of DHCPv6 Prefix Delegation to Clients, June 2025
• RFC 9926: Prefix Registration for IPv6 Neighbor Discovery, February 2026
• RFC 8981: Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6, February 2021
• RFC 7039: Source Address Validation Improvement (SAVI) Framework, October 2013
• RFC 6620: FCFS SAVI, First-Come, First-Served Source Address Validation, May 2012
• RFC 7513: Source Address Validation Solution for DHCP, May 2015
• RFC 7610: DHCPv6-Shield, Protecting against Rogue DHCPv6 Servers, August 2015
• IANA: Address Resolution Protocol (ARP) Parameters
• IANA: Internet Control Message Protocol version 6 (ICMPv6) Parameters
• IANA: IEEE 802 Numbers (EtherTypes)
• IEEE 802.1X: Port-Based Network Access Control
• Linux kernel documentation: IP sysctl
• ip-neighbour(8) Linux manual page
• ip(8) Linux manual page
• ip-address(8) Linux manual page
• arp(8) Linux manual page
• arp(7) Linux manual page
• sysctl(8) Linux manual page
• Microsoft Learn: Get-NetNeighbor
• Microsoft Learn: Get-NetIPInterface
• Microsoft Learn: Set-NetIPInterface

Last reviewed: 23 October 2026. Kernel defaults and switch feature behaviour change between releases; check the documentation for the exact kernel, Windows build and switch firmware you run.