We have been looking at the Neighbor Discovery protocol for IPv6, which performs functions like address resolution, duplicate address detection and so on. We have already looked at three out of nine of these functions, and in this article we will be looking at another function – Router Discovery.

Router discovery is the process by which hosts discover routers that are available on a link. Hosts use this information to build the default router list that we discussed in the previous article. The router discovery process also makes prefix lists (prefix discovery) and parameters (parameter discovery) available to hosts. As with other articles, we will use our network scenario to explain this process:

Solicited Router Discovery

For this article, I will be using a virtual machine as the “Host.” This makes it easy for me to explain what happens when a host comes online (e.g. power on) and initializes its network interface. The screenshot below is the result of the ipconfig/all command issued on that virtual host:

The ND protocol uses two ICMPv6 packet types for performing router discovery – Router Solicitation and Router Advertisement messages. When a host first comes online on a link, it will send Router Solicitation messages onto the link asking for information about the routers present on the link. This will help the host determine how it should perform address configuration (e.g. should DHCPv6 be used?) and also inform the host of the parameters used on the network such as the link MTU.

In our scenario, after the host came up, amongst the messages it sent was a router solicitation message as shown in the Wireshark capture below:

Let’s take a look at the router solicitation message in this capture.

As shown above, router solicitation messages are ICMPv6 messages with a type value of 133, and the only ICMPv6 option these messages can contain is the Source link-layer address option in which the soliciting host specifies its link-layer address.

By specifying a link-layer address in this message, receiving routers can create an entry for the host in their neighbor caches or update the entry if the entry already exists and the link-layer address specified in the received router solicitation message is different from what the router already has in its neighbor cache. Therefore, if we look at the neighbor cache on our routers, we should see an entry for the new host:

An instance where a router solicitation message will not include the Source link-layer address option is if the source IP address of that message is the unspecified address (“::”). This can happen when a host is just coming up and does not have an IP address yet. We saw this in a previous article.

The router solicitation message has a very simple format. The general format as defined by the RFC is shown below:

Let’s also take a quick look at the IPv6 header, paying special attention to the destination address.

When a host sends a router solicitation message, the message is basically saying, “Hey, any router out there?” Therefore, the message must be sent to a general (multicast) address that all routers listen on. We have talked about this multicast address before and this is the All-Routers multicast address, i.e. ff02::2. As an example, notice that R1 is listening on the all-routers multicast address (amongst other addresses):

Hint: There are two other all-router multicast addresses: ff01::2 (interface-local) and ff05::2 (site-local) – but since ND is restricted to a link, it will use the link-local scope all-routers multicast address ff02::2.

Continuing the router discovery process, if there are routers on the link, those routers will receive the router solicitation message and reply with Router Advertisement messages. In our scenario, there are two routers on the link so we see two router advertisement messages.

Let’s take a look at the content of this message.

First, we notice that router advertisement messages are carried in ICMPv6 messages with type 134. In this message, the Cur hop limit field is set to 64. This field specifies the hop limit that hosts should use for outgoing IPv6 packets. A value of zero means the router has not specified this option.

Next, we have the flags. Although RFC 4861 defines two flags (M and O), other RFCs define more flags like the Home Agent and Prf flags. Relevant to our discussion are the first two flags – Managed address configuration flag and the Other configuration flag.

When the Managed address configuration flag is set, it means IPv6 addresses are available via a DHCPv6 server. The Other configuration flag is used when the managed address configuration is not set and to inform hosts that other information (such as DNS) is available via DHCPv6. When neither of the flags is set, as in our scenario, it means no information is available via DHCPv6.

Following the flags, we have three different time-related fields:

  1. Router lifetime: Specifies the lifetime of the default router in seconds. After this time has passed and a router advertisement has not been received from this router, the host should stop using the router as a default router. A value of zero means that the host should not use the router that sent this router advertisement as a default router.
  2. Reachable time: This field is used in Neighbor Unreachability Detection and it specifies how long a node should consider that its neighbor is reachable after receiving a reachability confirmation. A value of zero means unspecified.
  3. Retrans timer: Specifies the time a host should wait in retransmitting neighbor solicitation messages. This field is used in address resolution and neighbor unreachability detection. A value of zero means unspecified.

Finally, this router advertisement message contains two ICMPv6 options. The first is the Source link-layer address option which contains the link-layer address (MAC address in this case) of the sending router. The second ICMPv6 option – MTU – is new to us. It conveys information about the maximum transmission unit (MTU) that all nodes on the link should use, especially in cases where the link MTU is not well-known. This MTU is an example of the Parameter Discovery function performed by the ND protocol.

There is a third ICMPv6 option that can be contained in router advertisement messages and this is the Prefix Information option. As we will see in the next article, this option helps in the prefix discovery function performed by ND.

The general format of the router advertisement message is as shown below. It seems to have the most complex format of all the ND message types.

Taking a look at the IPv6 header, we will see that this router advertisement message is sent to the all-nodes multicast address, i.e. ff02::1.

According to the RFC, a router that receives a router solicitation message from a source address other than the unspecified address can either unicast the router advertisement message to the sender or multicast it to the all-nodes multicast address. The latter is the “usual case,” and as we can see from above, the routers sent their advertisements to the all-nodes multicast address.

On receiving a router advertisement message, a host will add the router to the default router list. Notice from the screenshot below that our host has added both R1 and R2 to its default router list.

Note: Routers that send router advertisement messages with a Router lifetime of 0 are not added to this list.

Because of storage constraints, in the event of multiple default routers, the RFC specifies that a host must store at least two of those routers in its default router list. If one of the routers becomes unreachable, then the host can quickly switch to another one. How hosts select which default router to use in the event of multiple default routers is beyond the scope of this article but you can read more about that here and here.

Also, upon receipt of router advertisement messages, the host will create (or update) an entry for that router in its neighbor cache. Therefore, we should see two entries in our host’s neighbor cache for R1 and R2.

Unsolicited Router Advertisement

Apart from responding to router solicitation messages, routers will also send router advertisement messages onto the link frequently. The format of these messages is the same as we have already discussed except that their destination IP address will always be the all-nodes multicast address.


As we have seen, router discovery encompasses more than just how hosts discover routers that are available on a link. It also includes how hosts learn about parameters (Parameter discovery) and prefix lists (Prefix discovery).

In the next article, we will focus on prefix discovery which is also carried out using router advertisement messages. I hope you have found this article insightful and I look forward to the next article in the series.

References and further reading

  1. RFC 4861: Neighbor Discovery for IP version 6 (IPv6): http://tools.ietf.org/html/rfc4861
  2. RFC 4191: Default Router Preferences and More-Specific Routes: http://tools.ietf.org/html/rfc4191