Neighbor Discovery Protocol
| Communication protocol | |
 When defining its messages, NDP follows ICMPv6 message format. | |
| Purpose | Auxiliary protocol for IPv6 |
|---|---|
| Developer(s) | Internet Engineering Task Force |
| Introduction | March 1996 |
| OSI layer | Network layer |
| RFC(s) |
|
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 in an office (Computer 1 and Computer 2) are connected to each other in a local area network by Ethernet cables and network switches, with no intervening gateways or routers. Computer 1 has a packet to send to Computer 2. Through DNS, it determines that Computer 2 has the IP address 2001:db8::55.
To send the message, it also requires Computer 2's MAC address. First, Computer 1 uses a cached NDP table to look up 2001:db8::55 for any existing records of Computer 2's MAC address (00:EB:24:B2:05:AC). If the MAC address is found, it sends an Ethernet frame containing the IP packet onto the link with the destination address 00:EB:24:B2:05:AC. If the cache did not produce a result for 2001:db8::55, Computer 1 has to create a solicited-node multicast address by taking the least-significant 24 bits of Computer 2's address and appending them to the prefix ff02::1:ff00:0/104, which is ff02::1:ff00:55, and create a solicited-node multicast MAC address by taking the least-significant 24 bits of Computer 2's solicited-node multicast address and appending them to the prefix 33:33:FF:xx:xx:xx,[8] which is 33:33:FF:00:00:55, and send 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 Computer 2 which is listening on its own solicited-node multicast address on the local network.
Computer 2 responds with a neighbor advertisement message containing its MAC and IP addresses. As part of fielding the request, Computer 2 may insert an entry for Computer 1 into its NDP table for future use.
Computer 1 receives and caches the response information in its NDP table and can now send the packet.
Messages formats
[edit]-
Router Solicitation Message -
Router Advertisement Message -
Neighbor Solicitation Message -
Neighbor Advertisement Message -
Redirect Message
See also
[edit]- NDPMon – Neighbor Discovery Protocol Monitor
- radvd – Router Advertisement Daemon
- Secure Neighbor Discovery
References
[edit]- ^ a b c d T. Narten; E. Nordmark; W. Simpson; H. Holiman (September 2007). Neighbor Discovery for IP version 6 (IPv6). Network Working Group. doi:10.17487/RFC4861. RFC 4861. Draft Standard. Obsoletes RFC 2461. Updated by RFC 5942, 6980, 7048, 7527, 7559, 8028, 8319, 8425 and 9131.
- ^ R. Braden, ed. (October 1989). Requirements for Internet Hosts -- Communication Layers. Network Working Group. doi:10.17487/RFC1122. STD 3. RFC 1122. Internet Standard 3. Updated by RFC 1349, 4379, 5884, 6093, 6298, 6633, 6864, 8029 and 9293.
- ^ A. Conta, ed. (June 2001). Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification. Network Working Group. doi:10.17487/RFC3122. RFC 3122. Proposed Standard.
- ^ D. Thaler; M. Talwar; C. Patel (April 2006). Neighbor Discovery Proxies (ND Proxy). Network Working Group. doi:10.17487/RFC4389. RFC 4389. Experimental.
- ^ J. Jeong; S. Park; L. Beloeil; S. Madanapalli (March 2017). IPv6 Router Advertisement Options for DNS Configuration. Internet Engineering Task Force (IETF). doi:10.17487/RFC8106. ISSN 2070-1721. RFC 8106. Proposed Standard. Obsoletes RFC 6106.
- ^ J. Jeong; S. Park; L. Beloeil; S. Madanapalli (November 2010). IPv6 Router Advertisement Options for DNS Configuration. Internet Engineering Task Force (IETF). doi:10.17487/RFC6106. ISSN 2070-1721. RFC 6106. Obsolete. Obsoleted by RFC 8106. Obsoletes RFC 5006.
- ^ "IPv6 Neighbor Discovery Option Formats". Internet Control Message Protocol version 6 (ICMPv6) Parameters. Internet Assigned Numbers Authority. 2017-12-05. Retrieved 2017-12-16.
- ^ "IPv6 Real-Time Usage of IEEE 802.16: Problem Statement". www.ietf.org. Retrieved 2023-09-22.