Summary

  • SEND used a cryptographically generated address to bind a public key to an IPv6 interface identifier; a matching signature showed control of the associated private key, not a person's identity or a router's authority.
  • A host still needed a locally configured trust anchor to validate a router's certificate path. SEND made that bootstrap explicit rather than eliminating it.

Neighbor Discovery is one of IPv6's first conversations on a link. A host asks who is nearby, maps an IPv6 address to a link-layer address and learns which router may carry traffic beyond the link. If those messages are accepted without authentication, an attacker on the link can try to redirect or disrupt that early decision. The original Neighbor Discovery specification discussed IPsec protection, but RFC 3971 says the earlier documents did not give detailed instructions for using it here. Manually configuring security associations for the many potential peers could be impractical for most environments. SEND, Secure Neighbor Discovery, was the IETF's answer to that particular bootstrap problem.

Its solution is easier to understand as two separate proofs. For an ordinary node's address, SEND could use a Cryptographically Generated Address. RFC 3972 derives the interface identifier from a hash of a public key and auxiliary parameters. A verifier can recompute the hash and check a message signature made with the corresponding private key. No certificate authority is needed for this address-to-key binding. The proof says, in effect, “the signer controls the key associated with this address.” It does not say who the signer is in civil life, who assigned a subnet prefix, or whether a router should be trusted.

That last question follows a different path. A host deciding whether to accept Router Discovery information needs a router certificate chain that ends in a trust anchor the host already trusts. SEND's Authorization Delegation Discovery messages can help obtain a path from a peer. They do not create the host's trust anchor or make an unknown root authoritative. The root remains a configuration decision outside the exchange. SEND's “zero-configuration” address mechanism therefore did not mean that the whole system required no setup.

The asymmetry is the historical point. One side of the neighbor exchange could avoid a public-key infrastructure for proving local key possession. The router side kept explicit delegation. A single signed packet could not collapse “I can sign for this address” into “I am entitled to advertise a route.”

Later standards made the boundary more operational. RFC 6494 defined a SEND certificate profile based on resource certificates; RFC 6495 added a SEND name type for Subject Key Identifier fields. RFC 6980 later prohibited IPv6 fragmentation for specified Neighbor Discovery and SEND messages, addressing how fragmented packets could evade monitoring or filtering. These changes refine credential and packet-handling rules. They do not show how often SEND was deployed or whether a particular network became safer.

Read narrowly, RFC 3971 did not abolish trust. It assigned different evidence to different decisions: a cryptographic address binding for a node's signed claim, and a configured certification root for router authority. That is a more modest claim than “the address proves the owner,” and a more useful account of how the design works.