Neighbor Discovery for IP version 6 (IPv6)
obsoletes
- rfc-2461 — Neighbor Discovery for IP Version 6 (IPv6)
updated by
- rfc-5942 — IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
- rfc-6980 — Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
- rfc-7048 — Neighbor Unreachability Detection Is Too Impatient
- rfc-7527 — Enhanced Duplicate Address Detection
- rfc-7559 — Packet-Loss Resiliency for Router Solicitations
- rfc-8028 — First-Hop Router Selection by Hosts in a Multi-Prefix Network
- rfc-8319 — Support for Adjustable Maximum Router Lifetimes per Link
- rfc-8425 — IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags
- rfc-9131 — Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers
- rfc-9685 — Listener Subscription for IPv6 Neighbor Discovery Multicast and Anycast Addresses
- rfc-9762 — Using Router Advertisements to Signal the Availability of DHCPv6 Prefix Delegation to Clients
- rfc-9926 — Prefix Registration for IPv6 Neighbor Discovery
Extracted elements (30)
Address resolution multicasts are spread over 16 million (2^24) solicited-node multicast addresses, greatly reducing address-resolution-related interrupts compared to ARP broadcast. Non-IPv6 machines should not be interrupted at all.
Router Advertisements and Redirects use link-local addresses to identify routers, making it possible for hosts to maintain router associations during site renumbering to new global prefixes. Unlike IPv4 router discovery, RA messages carry no preference field because NUD detects dead routers and switches to a working one.
Setting the IPv6 Hop Limit to 255 for all ND messages makes Neighbor Discovery immune to off-link senders that accidentally or intentionally send ND messages, because routers decrement the hop limit and any message arriving from off-link will have a hop limit less than 255.
On Non-Broadcast Multi-Access (NBMA) links, address resolution and the multicast-dependent delivery of Router Solicitations and Advertisements are not specified by this document; alternative mechanisms must be defined per link type. Redirect, NUD, and next-hop determination SHOULD be implemented as described herein.
A router SHOULD NOT send a Prefix Information option for the link-local prefix, and a host SHOULD ignore such an option. Received Router Advertisements SHOULD NOT modify the invalidation timer for the link-local prefix.
All ND messages (RS, RA, NS, NA, Redirect) MUST be sent with IPv6 Hop Limit set to 255. Receivers MUST verify the Hop Limit is 255 and silently discard messages with any other value.
Nodes MUST silently discard any ND packet containing an option with a Length field of zero. Receivers MUST silently ignore any options they do not recognize and continue processing the rest of the message.
The Preferred Lifetime in the Prefix Information option MUST NOT exceed the Valid Lifetime field to avoid preferring addresses that are no longer valid.
The S (Solicited) flag in a Neighbor Advertisement MUST NOT be set in multicast advertisements or in unsolicited unicast advertisements; it is only valid in unicast responses to a specific Neighbor Solicitation.
The source address of a Router Advertisement MUST be the link-local address assigned to the sending interface. Hosts MUST silently discard RAs with source addresses that are not link-local.
The Source Link-Layer Address option MUST NOT be included in a Neighbor Solicitation when the IPv6 source address is the unspecified address. On link layers with addresses, it MUST be included in multicast solicitations and SHOULD be included in unicast solicitations.
The Target Address in Neighbor Solicitation and Neighbor Advertisement messages MUST NOT be a multicast address.
The Target Link-Layer Address option MUST be included in Neighbor Advertisement responses to multicast Neighbor Solicitations on link layers that have addresses, to avoid infinite NS recursion when the peer has no cache entry.
When a Redirect's target is a router (not the destination itself), the Target Address MUST be the router's link-local address so that hosts can uniquely identify routers across renumbering events. The Redirect source MUST be the link-local address of the sending interface.
Hosts and routers maintain four conceptual data structures per interface: Neighbor Cache (link-layer addresses and NUD state per neighbor), Destination Cache (next-hop IP per destination, updated by Redirects), Prefix List (on-link prefixes from RAs with lifetimes), and Default Router List (routers with lifetimes, favoring reachable ones).
Neighbor Advertisement (ICMPv6 Type 136) is sent in response to Neighbor Solicitations or unsolicited to announce link-layer address changes. It carries R (router), S (solicited), and O (override) flag bits plus a 128-bit Target Address.
Neighbor Solicitation (ICMPv6 Type 135) is sent to determine a neighbor's link-layer address or to verify reachability. It contains a 128-bit Target Address (MUST NOT be multicast) and optionally a Source Link-Layer Address option; it is multicast to the solicited-node address for resolution or unicast for NUD probing.
Redirect (ICMPv6 Type 137) is sent by routers to inform a host of a better first-hop for a destination. It contains a 128-bit Target Address (the better first hop or the destination itself when the destination is a neighbor) and a 128-bit Destination Address (the redirected destination).
Router Advertisement (ICMPv6 Type 134) is sent periodically or in response to Router Solicitations. It carries Cur Hop Limit (8-bit), M and O flags (1-bit each), Router Lifetime (16-bit, seconds), Reachable Time (32-bit, ms), and Retrans Timer (32-bit, ms), plus optional Prefix Information, Source Link-Layer Address, and MTU options.
Router Solicitation (ICMPv6 Type 133) is sent by hosts to prompt routers to generate Router Advertisements immediately. The source address is either an assigned interface address or the unspecified address if none is assigned; the destination is typically the all-routers multicast address (FF02::2).
This document defines five ICMPv6 message types for Neighbor Discovery: Router Solicitation (133), Router Advertisement (134), Neighbor Solicitation (135), Neighbor Advertisement (136), and Redirect (137). IANA maintains these in the ICMPv6 type number registry.
This document defines five ND option types maintained by IANA: Source Link-Layer Address (1), Target Link-Layer Address (2), Prefix Information (3), Redirected Header (4), and MTU (5).
A general solution for securing Neighbor Discovery is provided by SEND [RFC 3971], which uses cryptographically generated addresses and signatures. IPsec AH or ESP can also be used under specific constraints described in Section 11.2.
ND messages are vulnerable to spoofing attacks: a malicious node can forge Router Advertisements, Neighbor Advertisements, or Redirect messages to perform man-in-the-middle or denial-of-service attacks. The Hop Limit 255 check prevents off-link attackers but cannot prevent on-link attackers.
The Neighbor Cache entry for each neighbor cycles through five reachability states: INCOMPLETE (address resolution in progress), REACHABLE (recently confirmed reachable), STALE (no longer known reachable, not yet probed), DELAY (traffic sent, waiting for upper-layer confirmation before probing), and PROBE (unicast NS probes being sent). Transitions are driven by packet sends, received NAs, upper-layer hints, and probe timeouts.
All ND options use a TLV format: Type (8-bit), Length (8-bit, in units of 8 octets including Type and Length fields; value 0 is invalid), followed by variable data. Options are padded to 64-bit boundaries. Five option types are defined: Source Link-Layer Address (1), Target Link-Layer Address (2), Prefix Information (3), Redirected Header (4), MTU (5).
The MTU option (Type 5, Length 1) carries a 32-bit unsigned integer MTU value. It is used in Router Advertisements to ensure all nodes on a link use the same MTU on links without a well-defined MTU.
The Prefix Information option (Type 3, Length 4, 32 bytes total) carries Prefix Length (8-bit), L flag (on-link), A flag (autonomous address configuration), Valid Lifetime (32-bit, seconds), Preferred Lifetime (32-bit, seconds), Reserved2 (32-bit), and Prefix (128-bit). Preferred Lifetime MUST NOT exceed Valid Lifetime.
The Redirected Header option (Type 4) contains the original redirecting packet's IP header plus data, truncated so the Redirect message does not exceed the IPv6 minimum MTU. Reserved fields (16-bit + 32-bit) MUST be initialized to zero and ignored on receipt.
The Source/Target Link-Layer Address options (Type 1 and 2) carry a variable-length Link-Layer Address field whose byte and bit ordering is defined per link-layer document (e.g., [IPv6-ETHER]). For IEEE 802 addresses, Length is 1 (8 octets).