IPv6 Neighbor Discovery Mechanisms

There are nine Neighbor Discovery mechanisms that are implemented using the various Neighbor Discovery messages. These mechanisms are at the heart of IPv6.

The Neighbor Discovery mechanisms are:

 

Router Discovery 

At any time (but typically at power on) any IPv6 node can automatically discover the link local address(es) of the gateway router(s) on the local link. There is no need to manually configure a "default route" address for IPv6 nodes, although usually one can be manually configured if desired.

In IPv4, the each node must have the default gateway manually configured, or the node must obtain the default gateway from DHCPv4.

The node doing discovery send a Router Solicitation (RS) message to the all routers on local link multicast address (ff02::2). If the node already has a link-local address (virtually always the case), that address is used as the source address of the RS message, otherwise the unspecified address (::) can be used.

All of the routers on the local link will receive the RS message and each one will respond with a Router Advertisement message, sent to the all nodes on local link multicast address (ff02::1). The source address of each received RA message is added to the potential default gateway list, from which the preferred link-local default gateway address will be chosen. RA messages include the subnet prefix as well, including whether it is willing to perform as a gateway. If the router lifetime is greater than zero, it is willing, otherwise it isn't. If it isn't willing, then its address is not added to the potential default gateway list.

Router Discovery is performed as part of SLAAC.

There was a Router Discovery mechanism specified for IPv4: RFC 1256, "ICMP Router Discovery Messages", September 1991. It involves snooping the routing protocols, and is not a part of the base protocol. In IPv6, no such snooping is required. Router Discovery is part of the IPv6 base protocols, hence is mandatory on all IPv6 compliant nodes.

 

Prefix Discovery 

At any time, any IPv6 node can discover the 64-bit network prefix(es) in use on the local link. A network prefix is a globally unique 64-bit value, usually consisting of a 48-bit organizational prefix (e.g. 2001:db8:100::), followed by a unique within organization 16-bit subnet ID (e.g. 1000). Each node also creates one or more 64-bit suffix (or interface identifier) values. Appending the 64-bit suffix onto a 64-bit subnet prefix produces a globally unique 128 bit IPv6 unicast address. Duplicate Address Detection (DAD) is used to insure that such automatically generated addresses are in fact unique on the local link. If so, then the fact that the 64-bit prefix is globally unique insures that the entire 128 bit address is globally unique as well. For example:

48-bit organizational prefix       2001:db8:100::/48
16-bit Subnet ID                   1000
64-bit randomly generated suffix   ::9d94:8e5c:3a4b:942f

Complete 128-bit address           2001:db8:100:1000:9d94:8e5c:3a4b:942f

A 64-bit subnet prefix is obtained from a Prefix Information option included in a Router Advertisement message (which the node obtains by sending a Router Solicitation message to the all routers on local link multicast address). The prefixes obtained this way have usually been manually configured on the gateway router(s) in the subnet by the network administrator. Alternatively, routers can obtain subnet prefixes from a DHCPv6 server using prefix delegation. See RFC 3769, "Requirements for IPv6 Prefix Delegation", June 2004.

It is possible to have multiple subnet prefixes on a single physical subnet. A single Router Advertisement message could include multiple Prefix Information options. There can be multiple routers on a single physical subnet, each of which could advertise one or more prefixes. In general, IPv6 nodes that have SLAAC enabled will configure one (or more) global addresses from each advertised subnet prefix. This is in addition to any IPv6 unicast addresses generated automatically (e.g. the link-local address), manually configured, or obtained from a stateful DHCPv6 server.

 

Parameter Discovery 

Parameter Discovery works the same way as Prefix Discovery, by sending a Router Solicitation message to the the all routers on local link multicast address (ff02::2). The difference is the information desired (the Maximum Transmission Unit, or MTU) is in the MTU option in the returned Router Advertisement message. Unlike Prefix Information options, only one MTU option is returned per router, although every router will return an MTU option in its Router Advertisement message. All of the returned MTU values in a given subnet should be the same value.

 

Stateless Address Autoconfiguration (SLAAC)

SLAAC is covered in a separate article here.

 

Address Resolution (mapping IPv6 addresses to Link Layer addresses) 

Address Resolution is used to map IP addresses to Link Layer addresses, which are used to build an Ethernet frame. This is similar to the mapping of domain names to IP addresses done by DNS, but takes place at a lower level of the network stack.

In IPv4, address resolution is done by the ARP protocol. In IPv6, this is done by the Neighbor Discovery protocol.

Assume alice-pc (one node in a subnet) wants to send a packet to bob-pc (another node in the same subnet), using IPv6. The following explanation assumes the Link Layer protocol is Ethernet (which uses MAC addresses). Other Link-Layer protocols work in a similar manner, but may use other Link Layer addresses.

IPv6 Address Resolution involves 5 steps:

Step 1 - Alice-pc checks her Neighbor Cache (similar to the ARP cache in IPv4), to see if there is an entry with bob-pc's IPv6 address. If not, then she hasn't communicated with bob-pc recently, so if there had been an entry there before, it has expired. If she finds an entry, she has recently communicated with bob-pc and cached his MAC address. In this case, alice-pc can skip directly to Step 5.

Step 2 - Alice-pc creates a new entry in her Neighbor Cache for bob-pc, with his IPv6 address (no MAC address yet), with status = INCOMPLETE. Alice-pc then sends a Neighbor Discovery message to bob-pc. The source address of this request is set to the source address from the packet she wants to send (which is one of her IPv6 addresses). The destination address of this request is the Solicited Node Multicast address derived from bob-pc's IPv6 address. Alice-pc includes her own MAC address in a Source Link-Layer Address option, which insures that bob-pc will have her MAC address when he replies.

Step 3 - Bob-pc receives alice-pc's Neighbor Solicitation message. For future reference, bob-pc creates (or updates) alice-pc's entry in his own Neighbor Cache with the source IPv6 address from her request and the MAC address from the Source Link-Layer Address option from her request. He then replies with a Neighbor Advertisement message. The source address of this reply is one of his own link-local IPv6 address. The destination address is the source address from alice-pc's request. He includes his own MAC address as a Source Link-Layer Address option.

Step 4 - Alice-pc receives bob-pc's Neighbor Advertisement message, and adds his MAC address (from the Source Link-Layer Address option in his reply) to his incomplete entry in her Neighbor Cache.  Alice-pc then marks bob-pc's entry in her Neighbor Cache as REACHABLE.

Step 5 - At this point, alice-pc has bob-pc's MAC address (whether it was already in her Neighbor Cache, or had to be obtained from bob-pc). She can use it to create the Ethernet frame around the packet she wants to send, and then send it over Ethernet. Until bob-pc's entry in her Neighbor Cache expires, alice-pc can send bob-pc additional packets without having to ask for his MAC address again (using his entry in her Neighbor Cache). Once that expires though, the next time alice-pc wants to send bob-pc a packet, she will have to do another Address Resolution.

 

Next Hop Determination 

When one node wants to send a packet to another node, the sending node must first determine if the destination node is on-link (in the same physical subnet), or off-link (in some other subnet). To be considered on-link, the destination address must match at least one of the following criteria:

  • The address prefix must match one of the valid prefixes for this subnet.
  • The address is the target of a Redirect message send by a router, which informs the sender that the destination node is really in the sender's physical subnet.
  • The address is the target of a Neighbor Advertisement message.
  • The address is the source address of any ND protocol message received by the sender.

If the destination node is on-link, the the next-hop address is the same as the destination address. if it the destination node is off-link, then the next-hop address is the the sending node's default gateway address.

This mechanism is a bit different from the rest, since no packet transmissions are involved  (unless the sending node gets a Redirect response from its default gateway node).

 

Neighbor Unreachability Detection (NUD) 

This mechanism is used to determine the current reachability of other nodes in your subnet. This improves robustness of packet delivery in the presence of failing routers or links. It can identify "partially failing" links (where packets can go from alice-pc to bob-pc, but not from bob-pc to alice-pc). it also improves packet delivery to nodes that change their link-local address, such as mobile nodes that move off-link without losing connectivity due to stale ARP caches (which is what happens in IPv4).

Each entry in the Neighbor Cache on any IPv6 compliant node contains an IPv6 address, a link-layer (e.g. MAC) address, and the reachability status for some node elsewhere on the subnet. The Neighbor Cache is similar to the ARP cache used in IPv4, but it contains more information for each entry.

There are five possible states for each entry in the Neighbor Cache:

INCOMPLETE - a new cache entry is created (with a link-layer address of zero), and address resolution is in progress. Any transmitted packets to this node are queued. When the address resolution is complete, the link-layer address is added into the new entry, and the state is changed to REACHABLE.

REACHABLE - any packets queued for this node are immediately sent. Any newly transmitted packets are then sent normally. If more than a certain amount of time passes without any traffic to or from the address in the entry, then the reachability state changes to STALE.

STALE - the reachability of the node is unknown. The entry for a node remains in this state until traffic to that node is generated. At that point, the packets are queued and the state changes to DELAY.

DELAY - the entry remains in the DELAY state for a short period. The status is still unknown. Once the delay expires, a Neighbor Solicitation message is sent, and the state changes to PROBE.

PROBE - a Neighbor Solicitation message has been sent to the node to determine reachability. The status is still unknown. If the expected response (a solicited Neighbor Advertisement message) is seen, reachability has been confirmed, and the state changes to REACHABLE. If no response is forthcoming within a certain interval, then the node is considered to be unreachable. In that case, any queued traffic is discarded, the neighbor cache entry is discarded, and an ICMPv6 Time Exceeded message (with Code=0) is sent to the source address of any queued packets.

You can cause most or all of the link-local addresses of nodes in your subnet to be added into your Neighbor Table by doing a "ping ff02::1" ("all nodes in local link" multicast address). Nodes that had not been in the table previously will be shown in the PROBE state for a few seconds, then those that are reachable with go into the REACHABLE state for a short while, then they will go into the STALE state. If you do the ping again again, those nodes that are reachable will change from STALE to REACHABLE for a short while.

In NetConf, select the IPv6 Neighbors tab to see the contents of the IPv6 Neighbor Table. Try doing the "ping ff02::1" then hitting Refresh every few seconds to watch the states change.

The Reachable Time from the Router Advertisement message specifies how long (in milliseconds) that a node that has just done NUD can assume the node is still reachable.

There is nothing corresponding to NUD in the IPv4 specification. However, in Windows 7, Microsoft has implemented the same basic functionality as is found in IPv6 NUD, and extended the ARP cache to contain reachability information. Linux has also done this. There do not appear to currently be any RFCs that cover this. Where possible, certain IPv6 innovations are being retrofitted into IPv4 like this. However, this is like putting a new saddle on an old horse that is about to die. It's time to get a young, strong new horse.

In NetConf, select the IPv4 Neighbors tab to see the contents of the IPv4 Neighbor Table.

 

Duplicate Address Detection (DAD) 

This mechanism is used to determine if a proposed (TENTATIVE) address is already owned by some other node in the local link. Both hosts and routers perform DAD on all unicast addresses, regardless of how they are obtained (automatic generation, SLAAC, DHCPv6 stateful mode, or manual assignment). The only real difference in unicast and anycast messages is that DAD is not done for anycast addresses (and they can be assigned to multiple nodes in a single network). DAD is accomplished using Neighbor Solicitation and Neighbor Advertisement messages.

In IPv4 duplicate addresses would be accomplished by sending a Gratuitous ARP request.

There are several steps in IPv6 Duplicate Address Detection:

Step 1 - the node owning the TENTATIVE address sends several Neighbor Solicitation messages. The Retrans value from the Router Advertisement message specifies how many milliseconds to wait between the sent Neighbor Solicitation messages. The source address of these packets is the unspecified address (::). The Destination address is the solicited node multicast address for the TENTATIVE address. The Target address is the TENTATIVE address itself.

Step 2 - If any node on the local link is already using the TENTATIVE address, it will receive the multicast transmission (the any such node would have generated the right solicited node multicast address). Any such node will respond with a Neighbor Advertisement to the all nodes on local link multicast address (ff02::1). If no such response is seen within a reasonable time interval, then the TENTATIVE address is consider to be unique on the link and is assigned.

 

Redirect 

This mechanism is used by routers to tell sending nodes that there is a better next-hop address than itself for packets with a particular destination address. This is based on the router's better model of the outside world obtained via Routing Protocols and previous experience with delivering packets.

In the Packet Header:

The source address of the redirect packet is that address of the router sending the message.

The destination address of the redirect packet is the address of the node that sent the packet that needs to be redirected.

In the Redirect Message

The Target address is the address of the better next-hop router.

The Destination address is the destination address of the packet being redirected.

One option is included, which is the Link Layer Target Address, which is the MAC address of the better next-hop router.

The Redirect mechanism can also used by a default gateway node to inform an internal node that sent a packet to it for off-link delivery that the target is really on-link. In that case, the Target Address is set to the original Destination Address instead to the address of a better next-hop router. If those two addresses are the same, the target node is really in-link.

Because the Link Layer address of the recommended node (either the better next-hop router or the neighbor node) is contained in the Target Link Layer Address option, the sending node does not need to perform Address Resolution. This is just an optimization to save time.