IPv6 replaced ARP with the Neighbor Discovery Protocol (NDP, RFC 4861), a family of ICMPv6 messages that handle address resolution, router discovery, redirects, and Duplicate Address Detection. NDP is elegant — but in its base form it's spectacularly insecure. Any host on the link can send a Router Advertisement claiming to be the default gateway, poison neighbor caches with forged Neighbor Advertisements, or answer DAD probes to prevent legitimate hosts from acquiring addresses. It's ARP spoofing, upgraded to sixteen bytes of address space. RFC 3971 — SEcure Neighbor Discovery, or SEND — was the IETF's attempt to fix this without falling back on IPsec (which itself needs bootstrapping, a chicken-and-egg problem on a link where you don't yet know your router).

The core trick: Cryptographically Generated Addresses. SEND leans on CGAs (RFC 3972). Instead of picking a random or EUI-64 interface identifier, a host generates an RSA keypair and derives the low 64 bits of its IPv6 address from a hash of its public key plus a modifier. The address is a commitment to the key. Anyone receiving an NDP message signed by that key can verify the signer actually owns the source address — no PKI, no shared secret, no prior trust. This is a genuinely clever piece of design: it turns the address itself into a self-authenticating identifier, exploiting the 64 bits of entropy IPv6 gives you for free.

What SEND adds to NDP messages:

• CGA option — carries the public key and parameters so receivers can recompute the address hash.
• RSA Signature option — signs the message with the CGA's private key.
• Timestamp and Nonce options — block replay attacks (timestamps for unsolicited messages like RAs, nonces for solicited exchanges like NS/NA).
• Trust anchor and certificate options — for routers, which can't self-authenticate via CGA alone (you need to know a router is authorized, not just that it owns its address). Routers present X.509 certs chaining to a trust anchor the host is configured with.

Why you've probably never touched it. SEND is a fascinating protocol that essentially nobody deploys. Reasons: the RSA math was expensive for 2005-era hardware and remains a nuisance on constrained devices; router authentication requires provisioning trust anchors on every host, which defeats IPv6's autoconfiguration story; Windows never shipped a supported implementation; and Linux support (via the ipv6-send-cga patches and later ndprotector) has always been a research artifact. The operational world instead settled on link-layer mitigations: RA Guard (RFC 6105), DHCPv6-Shield, and switch-side ND inspection — treating NDP the way we treat ARP, with switch policies rather than crypto.

Why it still matters. First, CGAs themselves outlived SEND. They show up in Mobile IPv6, in Host Identity Protocol experiments, and in academic work on self-certifying identifiers — an ancestor of ideas you'll see in content-addressed networking and DIDs. Second, SEND is a case study in a recurring failure mode: cryptographically correct protocols that lose to operationally simpler ones. DNSSEC vs. DoH, S/MIME vs. TLS-to-the-MTA, SEND vs. RA Guard — the pattern is the same. Third, if you ever run a hostile IPv6 network (conferences, coffee shops, dorms), the fact that NDP is still unauthenticated by default is worth knowing: ndp-based attacks are trivial and modern OSes will happily accept a rogue RA.