Hubbry Logo
Neighbor Discovery ProtocolNeighbor Discovery ProtocolMain
Open search
Neighbor Discovery Protocol
Community hub
Neighbor Discovery Protocol
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Neighbor Discovery Protocol
Neighbor Discovery Protocol
Neighbor Discovery Protocol
View on Wikipedia
from Wikipedia
Neighbor Discovery Protocol
Communication protocol
When defining its messages, NDP follows ICMPv6 message format.
PurposeAuxiliary protocol for IPv6
Developer(s)Internet Engineering Task Force
IntroductionMarch 1996; 29 years ago (1996-03)
OSI layerNetwork layer
RFC(s)1970, 2461, 4861

The Neighbor Discovery Protocol (NDP), or simply Neighbor Discovery (ND), is a protocol of the Internet protocol suite used with Internet Protocol Version 6 (IPv6).[1]: §1  It operates at the internet layer of the Internet model,[2] and is responsible for gathering various information required for network communication, including the configuration of local connections and the domain name servers and gateways.

The protocol defines five ICMPv6 packet types to perform functions for IPv6 similar to the Address Resolution Protocol (ARP) and Internet Control Message Protocol (ICMP) Router Discovery and Router Redirect protocols for IPv4. It provides many improvements over its IPv4 counterparts.[1]: §3.1  For example, it includes Neighbor Unreachability Detection (NUD), thus improving robustness of packet delivery in the presence of failing routers or links, or mobile nodes.

The Inverse Neighbor Discovery (IND) protocol extension allows nodes to determine and advertise an IPv6 address corresponding to a given link-layer address, similar to Inverse ARP for IPv4.[3]

The Secure Neighbor Discovery Protocol (SEND), a security extension of NDP, uses Cryptographically Generated Addresses (CGA) and the Resource Public Key Infrastructure (RPKI) to provide an alternative mechanism for securing NDP with a cryptographic method that is independent of IPsec. Neighbor Discovery Proxy (ND Proxy) provides a service similar to IPv4 Proxy ARP and allows bridging multiple network segments within a single subnet prefix when bridging cannot be done at the link layer.[4]

Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

Functions

[edit]

NDP defines five ICMPv6 packet types for the purpose of router solicitation, router advertisement, neighbor solicitation, neighbor advertisement, and network redirects.[1]

Router Solicitation (Type 133)
Hosts inquire with Router Solicitation messages to locate routers on an attached link.[1]: §3  Routers which forward packets not addressed to them generate Router Advertisements immediately upon receipt of this message rather than at their next scheduled time.
Router Advertisement (Type 134)
Routers advertise their presence together with various link and Internet parameters either periodically, or in response to a Router Solicitation message.
Neighbor Solicitation (Type 135)
Neighbor solicitations are used by nodes to determine the link-layer address of a neighbor, or to verify that a neighbor is still reachable via a cached link-layer address.
Neighbor Advertisement (Type 136)
Neighbor advertisements are used by nodes to respond to a Neighbor Solicitation message, or unsolicited to provide new information quickly.
Redirect (Type 137)
Routers may inform hosts of a better first-hop router for a destination.

These messages are used to provide the following functionality:

  • Router discovery: hosts can locate routers residing on attached links.
  • Prefix discovery: hosts can discover address prefixes that are on-link for attached links.
  • Parameter discovery: hosts can find link parameters (e.g., MTU).
  • Address autoconfiguration: optional stateless configuration of addresses of network interfaces (see IPv6 § Stateless address autoconfiguration (SLAAC) and IPv6 address § Stateless address autoconfiguration).
  • Address resolution: mapping between IP addresses and link-layer addresses.
  • Next-hop determination: hosts can find next-hop routers for a destination.
  • Neighbor unreachability detection (NUD): determine that a neighbor is no longer reachable on the link.
  • Duplicate address detection (DAD): nodes can check whether an address is already in use.
  • Recursive DNS Server (RDNSS) and DNS Search List (DNSSL) assignment via a router advertisement (RA) options.[5] This is a proposed standard since 2010[6] and updated in March 2017, but not supported by all clients.[citation needed]
  • Packet redirection to provide a better next-hop route for certain destinations.

IANA maintains a list of all current NDP options as they are published.[7]

Example

[edit]

Two computers, A and B are connected to the same local area network with no intervening gateway or router. A has a packet to send to IP address 2001:db8::55 which happens to be the address of B.

Before sending the packet to B, A creates a solicited-node multicast address by appending the least-significant 24 bits of B's address to the prefix ff02::1:ff00:0/104, which is ff02::1:ff00:55 and creates a solicited-node multicast MAC address by appending the least-significant 24 bits of B's solicited-node multicast address to the prefix 33:33:FF:xx:xx:xx,[8] which is 33:33:FF:00:00:55. A sends a neighbor solicitation message requesting an answer for 2001:db8::55 (destination ff02::1:ff00:55 IP address and destination 33:33:FF:00:00:55 MAC address), which is accepted by B which is listening on its own solicited-node multicast address on the local network. B responds with a neighbor advertisement message containing its MAC and IP addresses. A receives the response and sends the packet on the link with B's MAC address.

Typically, network nodes maintain a lookup cache that associates IP and MAC addressees. In this example, if A had the lookup cached, then it would not need to send the NDP request. Also, when B received the request, it could cache the lookup to A so that if B needs to send a packet to A later, it does not need to use NDP to lookup its MAC address. Finally, when A receives the NDP response, it can cache the lookup for future messages addressed to the same IP address.

Messages formats

[edit]
  • Router Solicitation Message
    Router Solicitation Message
  • Router Advertisement Message
    Router Advertisement Message
  • Neighbor Solicitation Message
    Neighbor Solicitation Message
  • Neighbor Advertisement Message
    Neighbor Advertisement Message
  • Redirect Message
    Redirect Message

See also

[edit]
  • NDPMon – Software to monitor ICMPv6 packets
  • radvd – Server software for computer network configuration

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Neighbor Discovery Protocol

View on Grokipedia
from Grokipedia
The Neighbor Discovery Protocol (NDP) is a core component of the Internet Protocol version 6 (IPv6) suite, enabling nodes on the same local network link to automatically discover each other's presence, resolve IPv6 addresses to link-layer addresses, identify neighboring routers, and maintain reachability information. Defined in RFC 4861, NDP operates at the link layer and uses Internet Control Message Protocol version 6 (ICMPv6) messages to perform these tasks, providing a unified mechanism that replaces several IPv4 protocols including Address Resolution Protocol (ARP), ICMP Router Discovery, and ICMP Redirect. It supports stateless address autoconfiguration, allowing hosts to generate their own IPv6 addresses without a Dynamic Host Configuration Protocol (DHCP) server, and includes mechanisms for detecting duplicate addresses and optimizing neighbor interactions on low-power networks. NDP's primary functions encompass router discovery, where hosts solicit and receive advertisements from routers to learn about available gateways and network prefixes; prefix discovery, which informs nodes of the IPv6 address prefixes valid on the link for autoconfiguration; address resolution, akin to ARP but integrated with reachability checks; neighbor unreachability detection, which probes for active communication paths to avoid stale information; and redirect, enabling routers to inform hosts of more optimal next-hop destinations. These functions ensure efficient, secure, and dynamic neighbor management in environments, addressing limitations in IPv4 protocols by incorporating cryptographic protections in extensions like Secure Neighbor Discovery (SEND). The protocol relies on five main ICMPv6 message types: Router Solicitation (RS) for requesting router advertisements, Router Advertisement (RA) for broadcasting network parameters like prefixes and default gateways, Neighbor Solicitation (NS) for address resolution and duplicate detection, Neighbor Advertisement (NA) for responding to solicitations or unsolicited updates, and Redirect for route optimization. NDP messages include options for source link-layer addresses, target link-layer addresses, and prefix information, facilitating seamless integration with IPv6's addressing architecture. While robust for general use, operational challenges such as excessive advertisements or security vulnerabilities have led to optimizations and threat analyses in subsequent RFCs.

Background and Overview

Introduction

The Neighbor Discovery Protocol (NDP) is a core network layer protocol defined for Internet Protocol version 6 (), enabling nodes on the same local link to discover one another, resolve link-layer addresses, identify routers, and acquire essential network parameters. It operates using Internet Control Message Protocol version 6 () messages to facilitate these functions without relying on higher-layer protocols. NDP is integral to operations on link-local scopes, ensuring efficient communication among directly connected devices. NDP serves several primary purposes in IPv6 networks, including the replacement of key IPv4 mechanisms such as the (ARP) for address resolution, ICMP Router Discovery for locating gateways, and ICMP Redirect for optimizing next-hop paths. Additionally, it supports stateless address autoconfiguration (SLAAC), allowing hosts to generate their own addresses dynamically based on router advertisements, and provides neighbor unreachability detection (NUD) to monitor and confirm the ongoing viability of local connections. These capabilities collectively streamline link-local operations in IPv6 environments. Compared to its IPv4 counterparts, NDP offers key advantages, such as multicast-based communication that reduces network overhead by eliminating broadcast transmissions, potential integration with security extensions like Secure Neighbor Discovery (SEND) for and against spoofing, and enhanced robustness through proactive checks. The protocol was initially specified in RFC 1970 in 1996, obsoleted by RFC 2461 in 1998, and updated to its current form in RFC 4861 in 2007 to address clarifications and improvements in functionality.

Historical Development and Standards

The Neighbor Discovery Protocol (NDP) was initially developed as part of the early specification efforts by the (IETF) IPv6 Working Group, chartered in January 1995 to standardize next-generation Internet protocols addressing IPv4 limitations such as address exhaustion and inefficient neighbor discovery mechanisms like ARP. Introduced in RFC 1970 in August 1996, NDP provided IPv6 nodes on the same link with mechanisms to discover each other's presence, resolve link-layer addresses, and detect duplicate addresses, replacing fragmented IPv4 protocols. The protocol was refined and obsoleted by RFC 2461 in December 1998, which integrated NDP more closely with for message transport and expanded its scope to include router and prefix discovery functions essential for . Further updates came in RFC 4861 in September 2007, which obsoleted RFC 2461 to incorporate errata fixes, clarifications on message processing, and enhancements to neighbor unreachability detection (NUD) for improved reliability in dynamic networks. NDP relies on as defined in RFC 4443 (March 2006), which specifies the control message format and error reporting used by NDP's solicitation and advertisement exchanges. Implementations predating RFC 4861 may exhibit suboptimal NUD behavior, potentially leading to prolonged unreachability periods in certain scenarios. Subsequent extensions have built upon the core NDP framework without altering its foundational mechanisms. For instance, RFC 3122 (June 2001) introduced Inverse Neighbor Discovery to allow nodes to advertise addresses for given link-layer addresses, useful in environments. RFC 4389 (April 2006) defined Neighbor Discovery Proxy to enable bridging across network segments by proxying NDP messages, supporting mobile scenarios. Later adaptations include DNS configuration options via router advertisements in RFC 8106 (March 2017), facilitating stateless DNS server discovery. In low-power personal area networks () and IoT contexts, RFC 6775 (November 2012) optimized NDP by reducing overhead and enabling address registration, ensuring efficiency in resource-constrained devices. The core NDP specification has seen no major revisions since 2007, underscoring its stability within the suite.

Core Functions

Router and Prefix Discovery

Router Discovery in the Neighbor Discovery Protocol (NDP) enables hosts to identify neighboring routers on the same link, facilitating the automatic formation of default routes without manual configuration. Hosts initiate this process by multicasting Router Solicitation (RS) messages to the all-routers ff02::2, prompting nearby routers to advertise their presence. Routers respond to these solicitations with or Router Advertisement (RA) messages, which include the router's link-layer address and a Router Lifetime field indicating the duration for which the router can serve as a . This solicited exchange allows hosts to quickly discover routers upon interface activation or network attachment, typically within seconds. In addition to solicited responses, routers periodically send unsolicited RA messages to the all-nodes multicast address ff02::1 at intervals configurable via the Router Advertisement parameters, ensuring ongoing awareness for stationary hosts and supporting network changes. The Router Lifetime in these RAs determines whether a host installs or maintains a pointing to the advertising router; a zero value signals that the router is no longer available for forwarding off-link traffic. This dual mechanism—solicited for rapid initial discovery and unsolicited for periodic updates—enables robust router detection in dynamic environments, such as mobile networks. Prefix Discovery occurs through the Prefix Information Option included in messages, allowing hosts to learn the network prefixes associated with the link for address autoconfiguration and on-link determination. Each option specifies a prefix, along with Valid Lifetime and Preferred Lifetime timers that define the prefix's period for forming addresses and decisions. Key flags within the option include the A-bit, which indicates whether the prefix can be used for stateless address autoconfiguration, and the L-bit, which signifies if the prefix is considered on-link, meaning destinations within it are directly reachable without a router. By default, both flags are set, but administrators can adjust them to control behaviors like site-local addressing or to prevent unintended autoconfiguration. Beyond router and prefix information, RA messages convey essential network parameters to hosts, including the (MTU) for , the default Cur Hop Limit for outbound packets, and the Reachable Time value used in Neighbor Unreachability Detection (NUD). These parameters ensure consistent operation across the link, such as uniform hop limit enforcement to mitigate routing loops and MTU settings to avoid fragmentation. Retransmission timers and other tunable values in RAs further support adaptive behaviors, like adjusting intervals based on network conditions. Overall, these discovery mechanisms centralize configuration intelligence in routers, simplifying host deployment in networks.

Address Autoconfiguration and Duplicate Address Detection

Stateless Address Autoconfiguration (SLAAC) enables IPv6 hosts to generate their own unicast addresses without manual configuration or DHCPv6, using information from Router Advertisements (RAs) received via the Neighbor Discovery Protocol. When an RA includes a Prefix Information option with the A-bit (Autonomous flag) set, the host combines the advertised prefix with a 64-bit interface identifier to form a global unicast address. The interface identifier is typically derived from the host's link-layer address, such as using the EUI-64 format from the MAC address for Ethernet interfaces, ensuring a unique lower 64 bits of the address. This process begins with the host generating a link-local address using the prefix FE80::/64 and performing Duplicate Address Detection (DAD) before proceeding to global address formation upon receiving suitable RAs. The autoconfiguration steps are as follows: first, the interface is enabled and a link-local address is generated; second, DAD is performed on the link-local address; third, the host may send Router Solicitations to prompt RAs if needed; fourth, upon receiving an RA with the A-bit set, the host creates a tentative global address by appending the interface identifier to the prefix; fifth, DAD is executed on the tentative global address; and finally, if DAD succeeds, the address is assigned and its lifetimes are managed based on the RA's Valid Lifetime and Preferred Lifetime values. The Valid Lifetime determines how long the address remains valid for use, while the Preferred Lifetime specifies the period during which it is preferred for new communications; once the preferred lifetime expires, the address becomes deprecated but can still be used for existing connections until the valid lifetime ends, at which point it is invalidated. By default, the initial delay before sending a Neighbor Solicitation for DAD is a random value up to 1 second, with the number of transmissions governed by the DupAddrDetectTransmits parameter (default 1) and retransmission intervals set by RetransTimer (1 second). Duplicate Address Detection (DAD) is a critical component integrated into SLAAC to verify address uniqueness before assignment, preventing conflicts on the link. To perform DAD, the host sends a Neighbor Solicitation (NS) message with the unspecified IPv6 address (::) as the source and the tentative address as the target, directed to the solicited-node multicast address corresponding to the tentative address; this probes for any existing node using that address without including a Source Link-Layer Address option. If no Neighbor Advertisement (NA) response is received after the configured number of solicitations, the address is considered unique and can be assigned; however, an NA response indicates a duplicate, causing the host to abort assignment, log the conflict, and potentially deprecate the address. The NS and NA messages used in DAD include mechanisms to indicate tentative status, such as the unspecified source in NS. DAD is particularly vital in multi-homed environments, where it ensures address uniqueness across multiple interfaces, and in mobile scenarios, where it helps maintain consistent addressing during link changes, though mobile nodes may optimize solicitation delays for faster reconfiguration. Upon DAD failure due to a detected duplicate, the address is deprecated to avoid its use, prompting the host to generate a new interface identifier or seek alternative prefixes. To enhance privacy, SLAAC implementations often incorporate temporary addresses as defined in privacy extensions, which generate randomized interface identifiers using mechanisms like hashing of a history value or random data, combined with RA prefixes to create short-lived global addresses. These temporary addresses serve alongside stable addresses, regenerating periodically—typically every 24 hours for the preferred lifetime and valid for one week—to obscure the host's identity and prevent tracking based on consistent interface identifiers derived from hardware addresses like MACs. Like permanent addresses, temporary ones undergo DAD to ensure uniqueness before use. This approach balances autoconfiguration simplicity with needs in environments where address stability could enable long-term .

Neighbor Management

Address Resolution and Next-Hop Determination

The Neighbor Discovery Protocol (NDP) performs address resolution to map addresses to link-layer addresses for nodes on the same link, using Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages as a replacement for the . When a node needs to send a packet to an on-link destination, it first consults its Neighbor Cache; if no entry exists or the state requires resolution, the node sends an NS message to the derived from the target's address. The target node, upon receiving the NS, responds with an NA message containing its link-layer address in the Target Link-Layer Address option, allowing the sender to complete the resolution and update its cache. This process is performed only for on-link unicast or anycast addresses, ensuring efficient communication without broadcasting to all nodes on the link. Next-hop determination in NDP decides the immediate destination for packet forwarding based on whether the target IPv6 address is on-link or off-link. For on-link destinations, the next hop is the target itself, resolved directly via address resolution as described above. For off-link destinations, the node selects a default router from its Default Router List—populated by Router Advertisement (RA) messages—and sets that router as the next hop, encapsulating the packet accordingly. The resolved next-hop information, including the link-layer address, is stored in the Neighbor Cache to facilitate subsequent transmissions. The Neighbor Cache maintains entries for each neighbor, including the , corresponding link-layer address, an IsRouter flag indicating if the neighbor is a router, and a reachability state such as INCOMPLETE (during resolution), REACHABLE (recently confirmed), or STALE (unconfirmed but usable). When preparing an for transmission over a link like Ethernet, the node retrieves the next-hop's link-layer address from the cache to set the destination in the frame header. Cache entries are created upon receiving NS/NA or RA messages, updated with new link-layer information, and managed to prevent outdated mappings, with the IsRouter flag set based on NA or RA flags; extensions like gratuitous Neighbor Discovery (RFC 9131) enable proactive cache updates via unsolicited NAs when addresses change. Unlike IPv4 ARP, which relies on link-layer broadcasts and lacks integrated reachability checks, NDP uses ICMPv6-based for NS messages to reduce network overhead and supports addresses for resolution without special handling. Additionally, NDP's resolution integrates with neighbor unreachability detection mechanisms to validate cache entries dynamically, enhancing reliability in dynamic networks. This approach and compatibility make NDP more scalable for larger links compared to ARP's broadcast model.

Neighbor Unreachability Detection

Neighbor Unreachability Detection (NUD) is a mechanism in the Neighbor Discovery Protocol (NDP) that allows nodes to determine if a neighbor is no longer reachable on the local link, thereby maintaining an accurate neighbor cache and preventing packet transmission to unreachable destinations. This process is triggered primarily by upper-layer protocols, such as TCP, which provide reachability hints when expecting a response from a neighbor; in the absence of such confirmation, the node initiates probes to verify connectivity. NUD operates on entries in the neighbor cache, transitioning through specific states to confirm or invalidate reachability without unnecessary network traffic. The NUD process begins when a node has an entry marked as reachable in the neighbor cache, typically after successful address resolution or receipt of a positive upper-layer hint like a TCP acknowledgment. If no such hints are received within the reachable time and the node needs to send a packet, the state transitions to delay, where it waits briefly for potential upper-layer confirmation before probing. Upon entering the probe state, the node sends unicast Neighbor Solicitation (NS) messages to the neighbor's IPv6 address, with the source link-layer address included to solicit a Neighbor Advertisement (NA) response. Note that RFC 7048 relaxes these retransmission rules, permitting implementations to employ different, potentially longer timeout behaviors to reduce unnecessary probes. If no NA is received after a series of probes, the entry is marked unreachable, and the cache entry is deleted, prompting re-resolution or selection of an alternative next hop. This stateful approach ensures that probes are only sent to actively used neighbors, optimizing resource use. Neighbor cache states relevant to NUD include REACHABLE, where the neighbor is confirmed responsive; STALE, indicating potential unreachability without recent ; DELAY, a short waiting period post-stale to allow for hints; and , during active NS transmission. Transitions occur dynamically: from REACHABLE to STALE after the reachable time expires, to DELAY or when traffic is queued, and finally to unreachable if probes fail. Key timers govern NUD operations to balance responsiveness and network load. The Reachable Time, advertised in Router Advertisements (RAs) and typically set to 30,000 milliseconds (randomized between 0.5 and 1.5 times the value for diversity), defines the duration a neighbor remains reachable without confirmation. The Retransmission Timer, defaulting to 1,000 milliseconds, controls the interval between successive NS probes in the probe state. Additionally, a random Delay Time of up to 5 seconds (specifically, DELAY_FIRST_PROBE_TIME of 5 seconds) is observed before initiating probes from the delay state, allowing time for upper-layer protocols to detect issues independently. NUD integrates closely with address resolution by leveraging the same Neighbor Solicitation and Advertisement messages, but focuses on ongoing maintenance rather than initial discovery; it avoids redundant probes by confirming reachability before new transmissions, akin to optimizing ARP in IPv4 environments. This combination ensures efficient cache updates during redirects or path changes. The benefits of NUD include reduced in dynamic environments, such as mobile networks where nodes frequently change links, by promptly detecting failures and rerouting traffic. RFC 4861 enhances handling of router unreachability by allowing nodes to probe default routers and switch to alternatives upon failure detection, improving overall network robustness without relying on periodic polling.

Message Types and Formats

ICMPv6 Message Overview

The Neighbor Discovery Protocol (NDP) utilizes five specific message types to facilitate communication among nodes on the same link. These messages are defined with the following types and codes: Router Solicitation (Type 133, Code 0), Router Advertisement (Type 134, Code 0), Neighbor Solicitation (Type 135, Code 0), Neighbor Advertisement (Type 136, Code 0), and Redirect (Type 137, Code 0). Router Solicitation and Router Advertisement messages enable router discovery, where hosts send solicitations to prompt routers for advertisements containing network parameters such as prefixes and default gateways. Neighbor Solicitation and Neighbor Advertisement messages support resolution, Duplicate Address Detection (DAD), and Neighbor Unreachability Detection (NUD) by allowing nodes to query and respond with link-layer addresses or confirm reachability. The Redirect message allows routers to notify hosts of a better next-hop for improved efficiency. All NDP messages share common structural elements. The encapsulating header typically features a source address that is either link-local or unspecified (::), a destination address that is or depending on the message, and a hop limit of 255 to ensure link-local confinement. Following the header is the header, which includes the type, code, checksum, and message-specific data, often extended by variable-length options such as Source Link-Layer Address (to convey the sender's ), Target Link-Layer Address (for the target's ), and Prefix Information (detailing network prefixes). NDP messages frequently employ multicast addressing to target groups of nodes efficiently. Router Advertisements are sent to the all-nodes (ff02::1), while Router Solicitations target the all-routers (ff02::2). Neighbor Solicitations use the , formed by prefixing ff02::1:ff00:0/104 with the last 24 bits of the target's or address, enabling targeted queries without broadcasting to all nodes.

Detailed Message Structures

Neighbor Discovery Protocol (NDP) messages are carried within packets, sharing a common header structure consisting of a Type field (8 bits) identifying the message type, a field (8 bits) set to 0 for all NDP messages, and a field (16 bits) computed over the header, body, and an pseudo-header. Following the header, the message body varies by type and is followed by zero or more options in Type-Length-Value (TLV) format, with the entire message padded to a multiple of 8 octets for alignment.

Router Solicitation (RS)

The Router Solicitation message has Type 133 and an empty fixed body except for a Reserved field (32 bits, set to zero and ignored on receipt). It may include the Source Link-Layer Address option (Type 1).

Router Advertisement (RA)

The Router Advertisement message has Type 134 and includes the following fixed fields after the header: Cur Hop Limit (8 bits, default value for outgoing packets originating from the sending router), Managed address configuration flag (M, 1 bit), Other stateful configuration flag (O, 1 bit), bits (6 bits, set to zero and ignored), Router Lifetime (16 bits, time in seconds the router is valid), Reachable Time (32 bits, milliseconds a neighbor is considered reachable after last confirmation), and Retrans Timer (32 bits, milliseconds between retransmissions of Neighbor Solicitation messages). Options may include Source Link-Layer Address (Type 1), Prefix Information (Type 3), and MTU (Type 5).

Neighbor Solicitation (NS)

The Neighbor Solicitation message has Type 135 and a body consisting of a Reserved field (32 bits, set to zero and ignored) followed by the Target Address (128 bits ). It may include the Source Link-Layer Address option (Type 1).

Neighbor Advertisement (NA)

The Neighbor Advertisement message has Type 136 and a body with Router flag (R, 1 bit, indicating if the sender is a router), Solicited flag (S, 1 bit), Override flag (O, 1 bit), Reserved bits (29 bits, set to zero and ignored), and Target Address (128 bits ). It may include the Target Link-Layer Address option (Type 2).

Redirect

The Redirect message has Type 137 and a body with Reserved field (32 bits, set to zero and ignored), Target Address (128 bits of the better next hop), and Destination Address (128 bits of the destination being redirected). Options may include Target Link-Layer Address (Type 2) and Redirected Header (Type 4, containing the header plus 64 bits of the payload from the original packet).

Options

NDP options follow a TLV format with Type field (8 bits, values 1-7 defined), Length field (8 bits, length in 8-octet units excluding Type and Length fields), and variable Data field, padded to end on an 8-octet boundary. Specific types include Source Link-Layer Address (Type 1, containing the sender's link-layer address), Target Link-Layer Address (Type 2, containing the target's link-layer address), Prefix Information (Type 3, with Prefix Length (8 bits), on-link flag L (1 bit), autonomous address-configuration flag A (1 bit), Reserved1 (6 bits), Valid Lifetime (32 bits), Preferred Lifetime (32 bits), Reserved2 (32 bits), and Prefix (128 bits)), Redirected Header (Type 4, with 48 reserved bits followed by the header and 64 bits of the original packet's payload), and MTU (Type 5, with 16 reserved bits and MTU (32 bits)).

Security and Extensions

Vulnerabilities and Threats

The Neighbor Discovery Protocol (NDP), defined in RFC 4861, is susceptible to several security vulnerabilities due to its reliance on unverified messages for core functions like router discovery and address resolution. These vulnerabilities stem from the absence of built-in , allowing attackers on the local link to spoof messages and disrupt or hijack network operations. Rogue Router Advertisement (RA) attacks occur when a malicious node sends forged RA messages, impersonating a legitimate router to advertise false prefixes, routes, or default gateways. This enables traffic redirection, where hosts route packets through the attacker instead of the true gateway, facilitating man-in-the-middle interception or denial of service by isolating nodes from the network. Such attacks exploit the trust model where all on-link nodes are assumed benign, leading to compromised decisions across the link. Neighbor Solicitation (NS) and Neighbor Advertisement (NA) spoofing allows an attacker to falsify IP-to-link-layer mappings in the neighbor cache. By sending spoofed NA messages claiming ownership of a victim's , the attacker can steal the address, causing the victim's packets to be misdirected and enabling or DoS through . Spoofed NS messages can trigger unnecessary cache updates or reveal active hosts via responses, aiding network reconnaissance by enumerating devices and their es without authentication. These issues are particularly acute in Duplicate Address Detection (DAD), where forged NA responses during address autoconfiguration prevent legitimate hosts from using their tentative es. Redirect message hijacking involves spoofing Redirect messages to alter a host's next-hop path, often using a legitimate router's to maintain credibility. An attacker can sustain this by responding to subsequent Neighbor Unreachability Detection probes, diverting for or to overload specific paths, resulting in persistent man-in-the-middle attacks. Common threats include denial-of-service (DoS) via flooding RA or NS messages to exhaust router caches and processing resources, preventing legitimate discoveries and causing widespread connectivity loss. theft through spoofed NA claims erodes privacy by allowing impersonation, while via unsolicited NS floods maps the network , exposing host locations and active interfaces. These threats amplify in unsecured local area networks, such as environments, where link-local access is easy to obtain, leading to , , or service disruptions. Since NDP's initial specification in 1998, these vulnerabilities have persisted in unsecured deployments, with real-world exploits reported in transition networks during the , including RA flooding incidents that overwhelmed enterprise routers and public infrastructures.

Secure Neighbor Discovery and Proxies

The Secure Neighbor Discovery (SEND) protocol, defined in RFC 3971, extends the Neighbor Discovery Protocol (NDP) by incorporating cryptographic mechanisms to protect against spoofing and unauthorized modifications of NDP messages. It mandates the use of Cryptographically Generated Addresses (CGAs), as specified in RFC 3972, which bind an to a public key through a cryptographic hash, ensuring that only the address owner can generate valid signatures for messages originating from that address. SEND secures key NDP messages—such as Router Advertisements (RAs), Neighbor Solicitations (NS), and Neighbor Advertisements (NA)—by requiring digital signatures using the CGA's public key, while optional nonces provide replay protection to prevent message replay attacks. This approach obsoletes the implicit trust model in base NDP, replacing it with verifiable cryptographic proofs without relying on . Implementing SEND involves generating CGAs, which embed the public key hash in the interface identifier of the , and distributing public key certificates for trust validation, often through mechanisms like DNS Security Extensions (DNSSEC). While SEND effectively prevents address spoofing and unauthorized router advertisements, it introduces computational overhead from signature generation and verification, as well as increased message sizes due to cryptographic extensions. As of 2025, adoption remains limited primarily due to this complexity, the need for infrastructure support like certificate distribution, and the performance impact in resource-constrained environments, though security guidelines continue to recommend its use where feasible. Neighbor Discovery Proxy (ND Proxy), outlined in RFC 4389, enables a proxy node to respond to NS and NA messages on behalf of nodes that are not directly reachable on the local link, facilitating bridging of multiple network segments under a single prefix. The proxy generates Neighbor Advertisements with a Proxy flag set and restricted options to avoid forwarding loops or unauthorized redirects, making it suitable for scenarios like Mobile IPv6 where mobile nodes are hidden behind a home agent. In enterprise and VPN environments, ND Proxy supports efficient connectivity by allowing centralized gateways to handle discovery for remote or tunneled hosts, reducing broadcast traffic across bridged links. Additional extensions enhance NDP security through integration with for optional message authentication and integrity protection, providing an alternative or complementary layer to SEND in environments where is already deployed. For secure DNS configuration in RAs, RFC 8106 defines options to advertise DNS recursive resolvers and search lists, which can be protected using SEND signatures or to prevent tampering with DNS assignments.

Implementations and Examples

Software Tools and Deployment

The Neighbor Discovery Protocol (NDP) is natively integrated into the stacks of major operating systems, enabling automatic configuration and management without additional software in most cases. Windows has supported NDP since , where it handles functions like address autoconfiguration and neighbor unreachability detection through the kernel's implementation, configurable via the interface commands for settings such as router discovery and . Linux kernels include NDP via the ndisc module in the , allowing configuration through parameters like net.ipv6.conf.all.accept_ra to control router advertisement acceptance and neighbor solicitation behavior. macOS and provide built-in NDP support as part of their framework, with tools like or networksetup for adjustments, while Android incorporates NDP in its -based kernel for mobile connectivity, often managed through system properties. Several software tools facilitate NDP deployment, monitoring, and testing across systems. The daemon serves as a Router Advertisement sender for and BSD variants, enabling routers to advertise prefixes and routes for Stateless Address Autoconfiguration (SLAAC), with configuration files specifying advertisement intervals and lifetimes. NDPMon is a monitoring utility that captures and analyzes Neighbor Discovery packets, aiding administrators in detecting anomalies like duplicate address detections on networks; last updated in 2013, it remains available in some distributions but modern alternatives include Scapy-based scripts or Wireshark's IPv6 dissection capabilities. For client-side operations, dhclient from the suite supports address acquisition alongside NDP, integrating with Router Advertisements for hybrid and SLAAC environments. Testing tools include the ndp utility on for managing the neighbor cache, such as displaying or flushing entries, and the ip -6 neigh command in 's package for viewing and manipulating neighbor tables. Deployment of NDP involves enabling key features on routers and addressing network-specific challenges. On routers, SLAAC is activated using commands like ipv6 nd prefix and ipv6 nd ra suppress to advertise prefixes without managed address configuration flags, ensuring hosts autoconfigure addresses via NDP. Juniper devices similarly support SLAAC through set protocols router-discovery interface commands, allowing fine-tuned Router Advertisement parameters for and MTU announcements. In mixed IPv4/IPv6 environments, challenges arise from protocol isolation, such as NDP traffic not traversing IPv4-only segments, requiring dual-stack configurations or tunneling to maintain reachability without disrupting legacy IPv4 ARP operations. For low-power devices in personal area networks, RFC 6775 optimizes NDP by reducing usage, enabling neighbor solicitations, and simplifying duplicate address detection to conserve energy and bandwidth. Client support for advanced NDP options remains uneven, particularly for Recursive DNS Server (RDNSS) and DNS Search List (DNSSL) options defined in RFC 8106, which extend Router Advertisements to provide DNS configuration without relying solely on ; many implementations, including recent versions of Windows and Android as of 2025, exhibit limited or partial adoption, often falling back to manual DNS setup or other methods. To monitor for rogue Router Advertisements, Cisco's RA Guard feature filters unauthorized NDP messages at switch ports, configurable in device or router modes to block or log invalid RAs, enhancing security in enterprise deployments.

Practical Scenarios

In a typical local area network (LAN) scenario, an IPv6 host booting up multicasts a Router Solicitation (RS) message to the all-routers multicast address to discover neighboring routers and obtain network configuration information. The router responds with a unicast or multicast Router Advertisement (RA) containing the network prefix, default gateway, and other parameters, enabling the host to perform Stateless Address Autoconfiguration (SLAAC) by combining the prefix with its interface identifier to form a full IPv6 address. To verify address uniqueness, the host conducts Duplicate Address Detection (DAD) by sending a Neighbor Solicitation (NS) with its tentative address as the target; if no conflicting Neighbor Advertisement (NA) arrives within a short period, the address is considered valid and the host can proceed to communicate. For subsequent communication, when the host needs to send a packet to another node on the link, it resolves the target's link-layer address by sending an NS containing the target's IPv6 address; the target replies with an NA including its MAC address, allowing the sender to encapsulate the packet correctly. The address resolution process in this LAN setup can be visualized in a : the host initiates with an RS arrow to the router, followed by an response arrow back; then an NS loop for DAD with a for no response; finally, an NS arrow to the target node met with an NA response arrow, completing the resolution flow. In mobile scenarios, such as a node handing over between access points while maintaining connectivity on the same link, a previous router may issue a Redirect message to inform the mobile node of a superior next-hop router for specific destinations, updating its forwarding table to reduce latency. Concurrently, Neighbor Unreachability Detection (NUD) ensures reliability by having the mobile node periodically send unicast NS probes to the old router's IPv6 address; failure to receive an within the reachable time threshold (typically 3 retransmissions) declares the router unreachable, prompting the node to fall back to the redirected next-hop or solicit new advertisements. A common security threat involves rogue RA floods, where an attacker on the link broadcasts forged RAs with malicious prefixes or default routes, leading hosts to autoconfigure invalid addresses or route traffic to the attacker for interception or denial of service. Detection and mitigation can employ RA-Guard mechanisms on switches or routers, which inspect incoming RAs and drop those from unauthorized sources based on port validation or cryptographic verification from SEcure Neighbor Discovery (SEND). For instance, a basic simulation of an NS/NA exchange to test resolution under attack conditions might use the following Python pseudocode with the library to craft and send an NS, then sniff for the NA response:

from scapy.all import * # Craft NS for target IPv6 address target_ip = IPv6(dst="ff02::1") / ICMPv6ND_NS(tgt="2001:db8::1") sendp(target_ip / [Ether](/page/Ether)(), iface="eth0") # Sniff for NA response na = sniff(filter="icmp6 and ip6[40] == 136", count=1, timeout=5) # 136 is NA type if na: print("NA received:", na[0].summary()) else: print("No NA; possible unreachability or attack.")

from scapy.all import * # Craft NS for target IPv6 address target_ip = IPv6(dst="ff02::1") / ICMPv6ND_NS(tgt="2001:db8::1") sendp(target_ip / [Ether](/page/Ether)(), iface="eth0") # Sniff for NA response na = sniff(filter="icmp6 and ip6[40] == 136", count=1, timeout=5) # 136 is NA type if na: print("NA received:", na[0].summary()) else: print("No NA; possible unreachability or attack.")

This snippet illustrates probing a target and handling the response, adaptable for monitoring anomalies in NA authenticity. In advanced virtual machine (VM) environments, such as data centers, an ND Proxy operates on the or bridge to answer NS messages on behalf of isolated guest VMs, aggregating their ND traffic to avoid overwhelming the physical link with individual solicitations from thousands of virtual interfaces. The proxy maintains a binding table of VM IPv6 addresses to their virtual MACs, responding with NAs that use the proxy's link-layer address while tunneling packets to the appropriate guest, thus enabling seamless connectivity without exposing VMs directly to the underlay network. Additionally, routers can embed DNS configuration directly in RA options, advertising recursive DNS server addresses and search domains to hosts via the Recursive DNS Server (RDNSS) and DNS Search List options, streamlining name resolution without relying on separate exchanges.

References

  1. https://datatracker.ietf.org/doc/html/rfc4861
  2. https://datatracker.ietf.org/doc/html/rfc6775
  3. https://datatracker.ietf.org/doc/html/rfc3971
  4. https://datatracker.ietf.org/doc/html/rfc6583
  5. https://datatracker.ietf.org/doc/html/rfc3756
  6. https://datatracker.ietf.org/doc/html/rfc1970
  7. https://datatracker.ietf.org/wg/ipv6/about/
  8. https://www.rfc-editor.org/info/rfc1970
  9. https://www.rfc-editor.org/info/rfc2461
  10. https://www.rfc-editor.org/info/rfc4861
  11. https://www.rfc-editor.org/info/rfc4443
  12. https://www.rfc-editor.org/info/rfc8106
  13. https://datatracker.ietf.org/wg/ipv6/history/
  14. https://www.rfc-editor.org/rfc/rfc4861.html
  15. https://datatracker.ietf.org/doc/html/rfc4862
  16. https://datatracker.ietf.org/doc/html/rfc4862#section-5.5.3
  17. https://datatracker.ietf.org/doc/html/rfc4862#section-2
  18. https://datatracker.ietf.org/doc/html/rfc4862#section-5.3
  19. https://datatracker.ietf.org/doc/html/rfc4862#section-4
  20. https://datatracker.ietf.org/doc/html/rfc4862#section-5.5.4
  21. https://datatracker.ietf.org/doc/html/rfc4861#section-5.4
  22. https://datatracker.ietf.org/doc/html/rfc4862#section-5.4
  23. https://datatracker.ietf.org/doc/html/rfc4861#section-7.2.2
  24. https://datatracker.ietf.org/doc/html/rfc4861#section-7.2
  25. https://datatracker.ietf.org/doc/html/rfc4861#section-4.3
  26. https://datatracker.ietf.org/doc/html/rfc4861#appendix-a
  27. https://datatracker.ietf.org/doc/html/rfc4941
  28. https://datatracker.ietf.org/doc/html/rfc4941#section-3.5
  29. https://www.rfc-editor.org/rfc/rfc4861.html#section-7.2
  30. https://www.rfc-editor.org/rfc/rfc4861.html#section-5
  31. https://www.rfc-editor.org/rfc/rfc4861.html#section-5.2
  32. https://www.rfc-editor.org/rfc/rfc4861.html#section-6.3.6
  33. https://www.rfc-editor.org/rfc/rfc4861.html#section-5.1
  34. https://www.rfc-editor.org/rfc/rfc4861.html#section-7.3
  35. https://www.rfc-editor.org/rfc/rfc4861.html#section-7.2.1
  36. https://datatracker.ietf.org/doc/html/rfc9131
  37. https://www.rfc-editor.org/rfc/rfc4861.html#section-3.1
  38. https://www.rfc-editor.org/rfc/rfc4861.html#section-7
  39. https://www.rfc-editor.org/rfc/rfc4861.html#section-7.3.1
  40. https://www.rfc-editor.org/rfc/rfc4861.html#section-7.3.2
  41. https://datatracker.ietf.org/doc/html/rfc7048
  42. https://www.rfc-editor.org/rfc/rfc4861.html#section-4.2
  43. https://www.rfc-editor.org/rfc/rfc4861.html#section-8
  44. https://www.rfc-editor.org/rfc/rfc4861.html#section-6.3.7
  45. https://datatracker.ietf.org/doc/html/rfc4291
  46. https://datatracker.ietf.org/doc/html/rfc4861#section-4.1
  47. https://datatracker.ietf.org/doc/html/rfc4861#section-4.2
  48. https://datatracker.ietf.org/doc/html/rfc4861#section-4.4
  49. https://datatracker.ietf.org/doc/html/rfc4861#section-4.5
  50. https://datatracker.ietf.org/doc/html/rfc4861#section-4.6
  51. https://www.mdpi.com/2073-431X/12/6/125
  52. https://www.cvedetails.com/cve/CVE-2010-4671/
  53. https://nvd.nist.gov/vuln/detail/CVE-2010-4669
  54. https://datatracker.ietf.org/doc/html/rfc3972
  55. https://ieeexplore.ieee.org/document/7726976
  56. https://www.researchgate.net/publication/330049332_Secure_Neighbor_Discovery_Protocol
  57. https://www.cyber.gc.ca/en/guidance/security-considerations-internet-protocol-version-6-itsm80003
  58. https://datatracker.ietf.org/doc/html/rfc4389
  59. https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/967274/neighbor-discovery-proxy
  60. https://ieeexplore.ieee.org/document/7352509
  61. https://datatracker.ietf.org/doc/html/rfc8106
  62. https://sourceforge.net/projects/ndpmon/
  63. https://datatracker.ietf.org/doc/html/rfc6104
  64. https://datatracker.ietf.org/doc/html/rfc6105
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.