Table of Contents
IPv6 Neighbor Discovery Protocol
In IPv6 we do not have ARP (address resolution protocol) anymore. ARP is replaced with ICMP based NDP protocol. NDP or ND protocol uses special IPv6 ICMP messages to find and resolve L2 neighbours IPv6 addresses.
It’s a simple way for hosts to learn IPv6 addresses of neighbours on L2 subnet around himself. That includes learning about other hosts and routers on local network. That is the biggest difference between IPv4 and IPv6, there’s no ARP but ICMP takes the function.
NDP is defined in RFC 2461 and this article will introduce you to NDP functions, main features’ lists, and the related ICMPv6 message types.
As the most precise description of NDP is that it belongs to the Link layer of the Internet Protocol suite in TCP/IP model. We can say that Link layer of TCP/IP model is basically a direct combination of the data link layer and the physical layer in the OSI Open Systems Interconnection protocol stack. As in this blog I always try to use OSI model this article was inserted both to Data-link and Physical layer category.
NDP function
In case of IPv6 networks, the NDP Protocol make use of ICMPv6 messages and solicited-node multicast addresses for operating its core function, which is tracking and discovering other IPv6 hosts that are present on the other side of connected interfaces. Another use of NDP is address autoconfiguration.
Let’s discuss some major roles of IPv6 NDP:
- Stateless address autoconfiguration – SLAAC
- Duplicate address detection DAD
- Router discovery
- Prefix discovery
- Parameter discovery link MTU, hop limits
- Neighbor discovery
- Neighbor address resolution – replaces ARP in IPv6
- Neighbor and router reachability verification
In order to carry out work NDP uses five types of ICMPv6 messages. In the following list you can find the function as well as summary of their goals.
NDP message types:
-
Neighbor Advertisements
IPv6 nodes send Neighbor Advertisement (NA) messages periodically or repeatedly in order to inform their presence to other hosts present on the same network as well as send them their link-layer addresses.
-
Neighbor Solicitation
IPv6 nodes send NS messages so that the link-layer address of a specific neighbor can be found. There are three operations in which this message is used:
▪ For detecting duplicate address
▪ Verification of neighbor reachability
▪ Layer 3 to Layer 2 address resolution (for ARP replacement) ARP is not included in IPv6 as a protocol but rather the same functionality is integrated into ICMP as part of neighbor discovery. NA message is the response to an NS message. From the figure the enabling of interaction or communication between neighbor discoveries between two IPv6 hosts can be clearly seen.
-
Router Advertisement and Router Solicitation
A Cisco IPv6 router start sending RA messages for every configured interface prefix as soon as the configuration of the ipv6 unicast-routing command is entered. It is possible to change the default RA interval (200 seconds) with the help of the command ipv6 nd ra-interval. On a given interface the router advertisements include all of the 64-bit IPv6 prefixes that are configured on that interface. This permits stateless address autoconfiguration SLAAC to function and generate EUI-64 address. In case of RAs, link MTU and hop limits are included in the message as well as the info whether a router is a candidate default router or not.
In order to inform hosts about the IPv6 prefixes used on the link and also to inform hosts that the router is available as default gateway the IPv6 routers send periodic RA messages. A Cisco router that runs IPv6 on an interface advertises itself as a candidate default router. This happens by default. If you want to avoid advertising of the router as a default candidate use the command ipv6 nd ra-lifetime 0. A router informs the connected hosts about its presence by sending RAs with a lifetime of 0. It further tells connected hosts not to use it to reach hosts that are located or present beyond the subnet.
It is possible to hide the presence of a router completely in terms of router advertisements by simply disabling router advertisements on that router. It can be done by issuing the command ipv6 nd suppress-ra.
Ipv6 hosts at startup can send Router Solicitation (RS) messages to all-routers multicast address. It is quite helpful for the hosts on a given link to learn the router’s addresses. Sending RS message occurs without any waiting time for a periodic RA message. When there is no configured IPv6 address on host interfaces, RS message is sent from the unspecified source address. On the other hand, if the host has a configured address then the source of RS will be from that address.
Duplicate Address Detection
IPv6 DAD or Duplicate Address Detection is a neighbor solicitations function. When the address autoconfiguration is performed by host, that host does not automatically assume that the address is unique. It will probably be true that the address is unique if we know that EUI-64 process is generating the IPv6 address from MAC address which should be unique. Yes but what if there are some interfaces on that L2 subnet with manually configured IPv6 addresses? They could be configured just the same as the generated address, right? One more check is done just to be sure and that one is called DAD.
DAD works like this
- The host will firstly join the All Nodes multicast address and Solicited-Node multicast address of the address for which the uniqueness is being checked.
- Host then simply send few NS messages (Neighbor Solicitation messages) to the Solicited-Node address as the destination. The source address field will remain undefined with unspecified address which is written like this “::”.
- The address being checked is written inside Target Address field which we simple refer to as tentative address field.
The source of this message is an unspecified address (::) . There is a unique address in the Target Address field in the NS. If the host sending that kind of message receives an NA response it means that the address is not a unique one. The purpose of using this process by IPv6 hosts is to verify the uniqueness of both the addresses i.e. statically configured and autoconfigured.
An example is that when a host has autoconfigured an interface for the address 2001:128:1F:633:207:85FF:FE80:71B8, an NS is sent to the corresponding Solicited-node multicast address, FF02::1:FF80:71B8/104. If there is no answer from other host, the node comes to know that it is fine to utilize the autoconfigured address.
Solicited-node multicast address details and process of generating them from any random IPv6 unicast or anycast address is explained in more detail in article: Solicited-node multicast address from February 2015.
It is the most efficient method described here for a router to perform DAD, due to the reason that on the router same solicited-node address matches all autoconfigured addresses. (see the above section for a discussion of solicited-node addresses about “IPv6 Address Autoconfiguration”.)
Neighbor Unreachability Detection
It is easy for the IPv6 neighbors to track each other, basically in order to ensure that Layer 3 to Layer 2 address mapping stay current, with the use of information found out by different means. It is not only the presence of an advertisement of a neighbor or router that defines reachability but there is further requirement of confirmed, two-way reachability. However, it is not essential for a neighbor to ask another node for its existence and receive a reply directly as a result. Here are the two ways of a node confirms reachability:
- When a host sends a query to the desired host’s solicited-node multicast address then it is responded with an NA or an RA.
- When a host is interacting with the desired host then in response it gets a clue from a higher-layer protocol that two-way communication or interaction is properly functioning. A TCP ACK is one such clue. A point to note is that these clues from higher-layer protocols can only work for connection-oriented protocols. UDP, is such that does not accept frames and, so it cannot be utilized for verifying neighbor reachability. In such event when a host requires confirmation of another’s reachability where only connectionless traffic or no traffic is passing between these hosts then it is important for the originating host to send a query to the desired neighbor’s solicited-node multicast address.
Functions of ND in IPv6
Message Type | Information Sought or Sent | Source Address | Destination Address | ICMP Type, Code |
Router Advertisement (RA) | Routers advertise their presence and link prefixes, MTU, and hop limits. | Router’s link-local address | FF02::1 for periodic broadcasts; address of querying host for responses to an RS | 134, 0 |
Router Solicitation (RS) | Hosts query for the presence of routers on the link. | Address assigned to querying interface, if assigned, or :: if not assigned | FF02::2 | 133, 0 |
Neighbor Solicitation (NS) | Hosts query for other nodes’ link-layer addresses. Used for duplicate address detection and to verify neighbor reachability. | Address assigned to querying interface, if assigned, or :: if not assigned | Solicited-node multicast address or the target node’s address, if known | 135, 0 |
Neighbor Advertise- ment (NA) | Sent in response to NS messages and periodically to provide information to neighbors. | Configured or automatically assigned address of originating interface | Address of node requesting the NA or FF02::1 for periodic advertisements | 136, 0 |
Redirect | Sent by routers to inform nodes of better next-hop routers. | Link-local address of originating node | Source address of requesting node | 137, 0 |
I noticed an error in the article regarding the creation of the solicited node address:
it states “2001:128:1F:633:207:85FF: FE80:71B8, then an NS is sent to the corresponding solicited-node address, FF02::1:FE80:71B8/ 104.”
The correct solicited node address should be FF02::1:FF80:71B8/ 104 (just changed 1 character, E for F)
Hi,
Thank You for pointing out the error in the article. I looked it through and corrected the whole article a bit. IPv6 Solicited-node multicast address was corrected to FF02::1:FF80:71B8/104
nice blog post, i liked the table summary, it was very helpful