Neighbor Discovery Protocol

IPv6 Neighbor Discovery (ND) was first designed and published almost 10 years ago, as RFC 1970. It has been revised since then as RFC 2461, and a new version, focusing on fixes rather than revisions, is underway as RFC 2461bis. Some extensions have been described in Inverse Neighbor Discovery (RFC 3122), Default Router Selection (RFC4191), and Autoconfiguration (RFC 2462).

In these 10 years, the focus of the Internet community has shifted significantly, and areas that did not get much attention, such as security and mobility, are now the focus of most of the efforts. This change of focus has led to a number of extensions, clarifications, and interactions described in various RFCs and Internet Drafts: Extension for Mobility in MIPv6 (RFC 3775), Security Features in Secure Neighbor Discovery (SEND) (RFC 3971), Detecting Network Attachment (DNA) (RFC 4135), Protocol for Carrying Authentication for Network Access (PANA) (RFC 4058), and Optimistic DAD (draft-ietf-ipv6-optimistic-dad).

The IPv6 NDP provides a number of integrated key features for router and host operations, when attached to the same link. Some of these features, such as address resolution and redirect, are seen in IPv4, under specific distinct protocols such as ARP and ICMP Redirect, respectively. Other featuresfor instance, prefix discovery and neighbor unreachability detectionare new, although some could be achieved by other means with IPv4, too. Table 2-12 lists these features and their correspondence in IPv4.

Table 2-12. IPv6 NDP Feature Counterpart in IPv4

IPv6 ND Feature	Short Description	IPv4
Router discovery	Enables hosts to locate routers on attached links	ICMP Router Discovery (RFC 1256) Routing protocols snooping
Prefix discovery	Enables hosts to learn prefixes used on attached links	Not available
Parameter discovery	Enables nodes to learn parameters such as link MTU or hop limit	PMTU Discovery (RFC 1191)
Address autoconfiguration	Enables hosts to configure automatically an address	Not available
Address resolution	Enables nodes to determine link-layer address for on-link destinations	ARP
Next-hop determination	Enables nodes to determine the next hop for a given destination	ARP cache for on-link prefixes Default router otherwise
Neighbor unreachability detection	Enables nodes to detect that a neighbor is no longer reachable	Dead Gateway Detection (RFC 816, RFC 1122)
Duplicate address detection	Enables nodes to determine addresses already in use	ARP with source=0
Redirect	Enables routers to inform hosts of a better next hop on the link for a particular destination	ICMP Redirect
Default router and more specific route selection	Enables routers to inform multihomed hosts of better default routers and more specific routes
Proxying nodes	Accepts packets on behalf of other nodes	Proxy-ARP

NDP applies to both hosts and routers in different ways. Table 2-13 attempts to separate hosts and router roles, with regard to the preceding list of features.

Table 2-13. Host and Router Roles with Regard to NDP

Host Algorithms	Host-Host Communication	Host-Router Communication	Node-Node Communication
Default router selection	Neighbor unreachability detection	Router discovery	Address resolution
		Default router selection
Next-hop determination	Duplicate address detection	Prefix discovery	Redirect
		Parameter discovery
		More-specific route

One of the fundamental differences between IPv6 ND and its IPv4 counterpart suite of protocols (ARP, IPCP, and so on) is the positioning in the IP protocol stack. Although IPv4 same-link-related protocols are split between ARP/RARP, right above the link layer, and ICMP, running above IP, IPv6 ND is implemented entirely within ICMPv6. Figure 2-20 highlights differences between the protocol stacks.

Figure 2-20. IPv4 and IPv6 Protocol Stack Comparison

The reasons for the ND positioning within the stack are numerous, but if only one should be mentioned, it is simplicity. Why make address resolution (ARP and RARP in IPv4) a special case if this can be avoided? When within ICMP rather than next to IP, this feature can benefit from any service provided by IP, including security (Authentication Header), multicast, and so on.

To secure the various functions in NDP, Secure Neighbor Discovery has introduced a set of specific ND options. They are used to protect NDP messages. Although this IPv6 refresher does not go into more detail about these options, you can refer to RFC 3971 for more information about SEND.

Protocol Operations Summary

The NDP enables each node on the link to perform ND, to build the knowledge necessary to make proper decisions when sending IPv6 packets to a neighbor. This knowledge represents a compilation of advertisements received from routers and nodes. These advertisements can be solicited or unsolicited. This information is stored on the following lists maintained by nodes:

• List of on-link IPv6 addresses and corresponding link-layer addresses

• Neighbors status (reachable, unreachable)

• For hosts in particular:

  - List of on-link prefixes

  - List of on-link routers

  - List of default routers (on-link routers willing to be default routers)

To obtain the above information, the following messages are used in the NDP:

• Router solicitation (RS)

• Router advertisement (RA)

• Neighbor solicitation (NS)

• Neighbor advertisement (NA)

• Redirect

• Inverse neighbor solicitation (INS)

• Inverse neighbor advertisement (INA)

The positioning of NDP above IPv6/ICMP raises a couple of questions that deserve clarification.

When the link-layer address matching a given destination address is not known, a node seeking that association has to send its query to a wider audience. In IPv4, this is done using MAC-level broadcasts. In IPv6, the node uses multicasts for this query. The multicast group used is the solicited-node (with link-local scope), as described in the "IPv6 Addressing" section.

Note

Note that after the link-layer address is known for a prefix, the neighbor query might be sent again, to confirm the association (IP address, link-layer address). In that case, the query is directly unicasted to the destination.

Another issue arises when a node is using NDP to acquire its own address (see the section "Autoconfiguration"). It needs a source address to use for its query but has none yet. In such cases, it can use the IPv6 unspecified address (::) for the packet SA.

Whereas address resolution messages are sent to the solicited-node multicast address (with link-local scope), other NDP messages are expected to reach all nodes or all routers. At the same time, the SA can be either a global or the link-local address of the sender: The latter is always preferred, to minimize the node's dependency on renumbering. Here is a list of all special addresses, sources, and destinations that a node can use in NDP exchanges:

• All-nodes multicast address (FF02::1, destination)

• All-routers multicast address (FF02::2, destination)

• Solicited-node multicast address (destination)

• Link-local address (source or destination)

• Unspecified address (::, source)

Finally, two algorithms are leveraged by the IPv6 nodes to process the information gathered through NDP:

• Next-hop determination algorithm

• Default router selection

Comparison with IPv4

IPv6 NDP provides a number of improvements over the corresponding IPv4 protocols, as follows:

• Router discovery becomes an integrated part of the protocol, enabling hosts to identify their default router.

• Additional information, such as MTU or link-layer address, has been inserted in the ND messages, reducing the number of required exchanges on the link to achieve the same result as in IPv4. Here are a few examples:

  - The link-layer address of the router is carried in RA message. So all nodes on the link, without any further message flow, know it.

  - The target link-layer address, inserted in the redirect message, saves the receiver (being redirected) any extra address-resolution exchange.

  - The MTU, carried in the RA, enables all nodes on a link to use a consistent MTU.

• The address resolution uses multicast groups (solicited-node multicast address), embedding part of the target address. Most likely, therefore, only a few (most of the time only the target address owner) nodes will get interrupted with such address-resolution queries. Compare this with IPv4 ARP, which has no other choice than broadcasting (link-layer broadcast) the address-resolution requests (because ARP sits directly above the link layer). One hopes that the IPv6 way of resolving link-layer addresses will make subnets with a much larger number of hosts more manageable by drastically limiting link-layer broadcasts that host software layers have to handle.

• Some new features such as address autoconfiguration and neighbor unreachability detection are part of the base protocol, simplifying configurations and improving robustness of packet delivery.

• Router advertisements and Redirect messages carry router addresses in the form of link-local addresses, which makes the router association in the host more robust to renumbering (of global prefixes). In IPv4, the default gateway information has to be modified on the host every time the network changes its addressing scheme.

• The positioning of address resolution above ICMP makes it possible to use standard IP authentication and security mechanisms for ND messages. Such mechanisms are not available in ARP for IPv4.

Router and Prefix Discovery

Router discovery enables hosts to locate neighboring (on-link) routers and learn prefixes and parameters related to address configuration.

Two messages have been defined for router and prefix discovery: the router solicitation (RS) message and the router advertisement (RA) message.

Routers advertise themselves periodically (with a slight randomization to avoid synchronization, which could leave some time intervals with no routers being advertised) out of each interface by sending RAs. These unsolicited RAs are sent to the all-nodes "link-local scope multicast address" (FF02::1). In addition to providing the router address, RAs can contain useful information for hosts to perform next-hop determination, such as the following:

• List of candidate routers for default router (see the algorithm described in the "Default Router Selection" section)

• Parameters that should be used for autoconfiguration (see the "Autoconfiguration" section)

• List of on-link prefixes (see the "Next-Hop Determination" section later in this chapter). This information makes the router discovery messages useful in the prefix discovery process.

The RA messages can also be sent as a response to a query (RS) from a host. This option proves particularly useful in mobility, to accelerate autoconfiguration. These solicited RAs are sent either to the all-nodes address or to the unicast address of the host, which issued the RS. As the RS is soliciting a response from on-link routers, it is typically sent to the all-routers multicast group. Figure 2-21 shows the flow for a solicited and for an unsolicited RA exchange.

Figure 2-21. Router Advertisement Flow

Note

In the case of a solicited RA, when the RS does not provide any IPv6 SA (typical for hosts that rely on RAs to autoconfigure themselves), the RA response is sent to all nodes.

Figure 2-22 shows a simple example of a Cisco router (Valbonne) sending a periodic RA to a host (host1). The interface configuration is grayed, the NDP debugging is enabled, and the debug output is shown below the RA flow.

Figure 2-22. Router Advertisement Example

Figure 2-22 shows a debug trace interleaved with the RA flow.

The show ipv6 routers command is used on a Cisco router to display RA information received from other on-link routers. Only the router sends RAs, and only the hosts install them in their database. So in the configuration in Figure 2-22, this command applies only to host1 (a Cisco router in host mode). Example 2-10 shows the output of this command.

Example 2-10. Host Perspective of Advertised Routers.

host1#show ipv6 routers Router FE80::A8BB:CCFF:FE01:F600 on Ethernet0/0, last update 2 min   Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500   Reachable time 0 msec, Retransmit time 0 msec   Prefix 2001:100::/64 onlink autoconfig     Valid lifetime 2592000, preferred lifetime 604800   Prefix 2001:200::/64 onlink autoconfig     Valid lifetime 2592000, preferred lifetime 604800

Address Resolution

The neighbor solicitation and neighbor advertisement packets are used to perform several critical node operations:

• Link-layer address resolution

• Duplicate address detection (DAD)

• Neighbor unreachability detection (NUD)

DAD and NUD are described in next sections. ND link-layer resolution provides a similar service to ARP in IPv4, although using a slightly different method.

Two ICMPv6 messages have been defined for IPv6 address resolution: the neighbor solicitation (NS) message and the neighbor advertisement (NA) message. The NS is the query and contains the target (queried) IPv6 address. The NA is the response and contains the link-layer address of the matching interface.

When a node has concluded that a particular next hop or destination IPv6 address is on-link (see the section "Next-Hop Determination" later in this chapter), it sends out an NS on the identified link, to obtain the link-layer address matching the IPv6 address. The expected response is an NA.

The NS is a multicast to the solicited-node multicast group, embedding the rightmost 24 bits of the queried IPv6 address. There are potentially multiple nodes subscribed to the same solicited-node multicast address, with the "owner" of that address being one of them. The owner will get the NS along with the other members of the multicast group, and answer with an NA.

Note

NDP is a nonreliable protocol. On most link types, this is fine, because the probability of "losing" a message, such as an NS or NA, is low. On wireless links, however, this may become an issue. In particular, DAD could conclude that an address is free to use, whereas in fact, the NA was lost.

A host can also send an unsolicited NA. This could happen when the node wishes to inform the other nodes on the link about a change in their link-layer address. The unsolicited NA is sent to all-nodes multicast address.

After the node has received the NA, the neighbor from whom it has been received is considered "reachable." Monitoring the reachability is the purpose of NUD. See the sections "Neighbor Unreachability Detection" and "The State Machine for Reachability" for details. Figure 2-23 shows the flow for the address-resolution process.

Figure 2-23. Address-Resolution Flow

On Cisco routers, the association (layer 3 address, link-layer address) is stored in the neighbor cache. The command show ipv6 neighbor executed on each router lists the neighbor cache content. In Example 2-11, the biot neighbor cache has two entries that relate to router valbonne: 2001:200::72b and FE80::A8BB:CCFF:FE01:F600. They are listed in "reachable" state along with the corresponding link-layer address.

Example 2-11. Example of IPv6 Neighbor Cache

biot#show ipv6 neighbor IPv6 Address                   Age   Link-layer          AddrStateInterface 2001:200::72B                  0     aabb.cc01.f600      REACH Et0/0 FE80::A8BB:CCFF:FE01:F600      0     aabb.cc01.f600      REACH Et0/0

Redirecting a Host to a Better Next Hop

Routers send redirect messages to inform hosts of a better next hop, whether another router or the final destination itself, should it be on-link. The IPv6 redirect mechanism is similar to the IPv4 redirect mechanism. Only one message, the redirect message, is necessary to achieve the redirect functionality. It contains the IP address that is a better next hop and the IP address of the destination that is redirected. If the link-layer address of the better next hop (R2) is known, it can be inserted in the redirect packet sent by the router (R1) issuing the redirect message.

Note

In theory, the previously described process could save an address-resolution exchange between the host and the router R2. In practice, the benefit may be limited. The router R2 is likely, at some point, to route some traffic back to the host. To do so, it will need to initiate an NS/NA exchange to determine the host link-layer address. This flow would have been unnecessary had the host initiated an address-resolution flow to find R2's link-layer address. The link-layer address of the initiator of the NS can indeed also be inserted, as an option, in the NS packet.

Figure 2-24 shows the flow for the redirect message.

Figure 2-24. Redirect Flow

Inverse Neighbor Discovery

As mentioned earlier, ND fulfills, for IPv6, the same functionality as ARP does for IPv4. In this context, similar reasons that drove an inverse-ARP protocol led to extensions to IPv6 ND called IPv6 Inverse Neighbor Discovery (IND). The details of this extension are specified in RFC 3122.

The IPv6 IND enables a node to learn IPv6 addresses for which it knows the link-layer address. To achieve this, it sends solicitations and receives advertisements. The IND was originally developed for Frame Relay networks, but may also apply to other data-link technologies with similar behavior. Two messagesthe inverse neighbor discovery solicitation (INS) and the inverse neighbor discovery advertisement (INA)have been defined. The INS contains the source link-layer address and the target link-layer address (for which the sender expect to get an IPv6 address). The response (INA) contains the source link-layer address, the target link-layer address, and a target address list. It contains the list of one or more IPv6 addresses of the interface identified by the target link-layer address in the INS message that prompted the INA.

Note that at the time of this writing, RFC 3122 is not supported on Cisco routers.

Proxy Neighbor Discovery

An IPv4 node has the capability to proxy subnets for hosts that do not understand subnet (or are misconfigured) or default routers. This function is sometimes referred to as proxy-ARP and is specified in RFC 1027. IPv6 does not carry over that concept; instead, it requires IPv6 hosts to process RAs and to come up with a default router to which nonlocal traffic can be sent. Furthermore, proxying an entire subnet might be, for many systems, impractical. They could set the interface in promiscuous mode, or all-multicast mode, to receive all NSs, but, besides performance issues this potentially raises, not all systems support these modes.

In some cases, however, it might prove useful for a router to act on behalf of nodes that are away from the link but want neighbors to believe they are not. A classical example is a mobile node that has moved off-link. To achieve this limited proxy address-resolution function, the router just has to register to the solicited-node multicast addresses it wants to proxy and answer NSs on their behalf.

Neighbor Discovery Algorithms

A number of ND algorithms have been defined to describe the expected behavior of both hosts and routers in a variety of operational situations. The following subsections discuss these algorithms:

Next-Hop Determination

As in IPv4, a node that needs to forward a packet must find out whether the destination is on-link or off-link. In the latter case, it must subsequently find an on-link neighbor (next hop) that can forward the packet to the destination. Finally, it has to resolve the on-link destination address, or the on-link next hop, into a link-layer address.

Unlike IPv4, a destination (or next hop) can be on-link, without the forwarding node having a prefix matching the destination address. An address will be considered on-link by a node if

• It is covered by one of its link's prefixes.

• It received an NA for that address.

• It received any ND message from that address.

• It received an RA with this prefix in the prefix information option.

• It received a redirect message with a target equal to that address.

The algorithm used to forward a packet is set fairly differently on hosts or routers. A router has a routing table and a neighbor cache (same as ARP cache for IPv4). The first one (the Routing Information Base, or RIB) contains next hops for a given destination match (longest match); the latter contains link-layer addresses for on-link nodes, either final destination or next hops. Cisco routers also have a forwarding table (Forwarding Information Base, or FIB), which takes the RIB one step further by pre-resolving recursive entries to accelerate the forwarding process. In routers, regular routing mechanisms take precedence over information obtained from neighboring routers via prefix discovery or router discovery mechanisms. Then NS/NA messages enable link-layer resolution.

Example 2-12 shows the routing tables and the neighbors of a router in Figure 2-24.

Example 2-12. Routing and Neighbor Information on an IPv6 Router

valbonne#show ipv6 route IPv6 Routing Table - default - 7 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP        U - Per-user Static route        I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary        O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2        ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 C   2001:100::/64 [0/0]      via Ethernet0/0, directly connected L   2001:100::72B/128 [0/0]      via Ethernet0/0, receive C   2001:200::/64 [0/0]      via Ethernet0/0, directly connected L   2001:200::72B/128 [0/0]      via Ethernet0/0, receive L   FF00::/8 [0/0]      via Null0, receive valbonne#show ipv6 neighbors IPv6 Address                 Age   Link-layer Addr  State  Interface 2001:200::72A                1     aabb.cc01.f400   STALE  Et0/0 FE80::A8BB:CCFF:FE01:F400    1     aabb.cc01.f400   STALE  Et0/0

On hosts, on the other hand, no such thing as a routing table or routing protocols should be necessary.

RFC 2461 describes a set of conceptual data structures to enable next-hop determination in hosts:

• Destination cache Contains destinations to which traffic has been forwarded recently, with the next hop (neighbor) that was chosen providing linkage into the neighbor cache. This cache is updated with information obtained from redirect messages.

• Prefix list Contains the list of prefixes that match the on-link addresses. This list is built from RA messages.

• Default router list Contains the list of on-link routers to which packets can be sent.

Figure 2-25 shows a host model of the next-hop determination algorithm, based on RFC 2461.

Figure 2-25. Next-Hop Determination Algorithm

The host first does a lookup into the destination cache, in case the destination of the packet has been seen recently. If so, the destination cache provides the next hop that was used (may be the destination itself), and a subsequent lookup into the neighbor cache is likely to provide the link-layer address. This path, shown in bold, will be the most exercised on an established flow. If the destination is not in the destination cache, it is searched in the prefix list (maintained from information received in RAs). As a last resort, a default router is selected, from among all on-link routers (known by sending RAs), via default router selection.

Default Router Selection

Again, this is a host-specific algorithm. Routers just rely on routing protocols (and routing tables) to make proper next-hop determinations.

Unlike IPv4, a default gateway does not have to be defined on an IPv6 host. The procedure for a host to select a router as the next hop for its traffic is described in the "Default Router Preference and More-Specific Routes" Internet Draft. It identifies three distinct types of hosts:

• Type A Hosts that ignore default router preference, as well as more specific routes listed in the RA option Route Information. (See the section "Router and Prefix Discovery" for details.) These hosts simply run the router selection algorithm as described in RFC 2461. Basically, a type A host selects a default router from its default router list (built from RAs received from routers sharing a link with the host). It should prefer a reachable router if any are available (known as reachable, according to the state machine; see the section "The State Machine for Reachability") or any other router on the list, if available. If the selected router is not known as reachable, it should be selected in a round-robin fashion from among all the routers on the list (thus ensuring that all routers on the list are probed by the neighbor unreachability detection algorithm).

• Type B Same as type A hosts, where the default router list is augmented by the preference (Low, Medium, High) received in the RAs. The default router selection can be based on this preference rather than being round robin.

• Type C Hosts that implement a routing table. When they receive an RA with a number of occurrences of the Route Information option, they install a default route, ::/0, pointing to the router that issued the RA; they also install (or remove if the lifetime is 0) one route to the prefix found in the Route Information option, per occurrence. When a type C host does next-hop determination and consults its routing table for an off-link destination, it first prefers reachable routers over nonreachable routers; then it uses the longest-matching prefix; after that, it uses route-preference values.

Note that hosts of different types, receiving the same RA packets (multicast on the link), might end up making different decisions when selecting a default router.

Note

As mentioned previously, each router on the link may advertise a list of prefixes as well as offer itself as the default router. A dual-homed host could potentially receive disjoint prefix lists from two or more routers, and pick up one prefix from one list for autoconfiguration, forming an SA. It could then use this address (selected using SAS) to leave the subnet, via the router (selected as the default router) that did not advertise the prefix used to form this address.

Duplicate Address Detection

The NS and NA messages are also used to perform duplicate address detection (DAD), as described in RFC 2462. DAD is performed on all unicast addresses prior to assigning them to an interface. The basic principle is that a node sends an NS to query about an IPv6 address ownership, and assigns the address to one of its own interfaces only if no NA was received for it.

Optimistic DAD is proposing a modification of the existing IPv6 ND (RFC 2461) and stateless address autoconfiguration (RFC 2462) algorithms. The intention is to minimize address configuration delays in the successful case (the address chosen by the node is unique), and to reduce disruption as far as possible in the failure case. Optimistic DAD is only performed on automatically configured addresses. It is a useful optimization because DAD is far more likely to succeed than fail for a well-distributed random address or for an interface IDbased address constructed in the modified EUI-64 format from the unique MAC.

Note

DAD must not be performed on anycast addresses because by definition an anycast address can belong to multiple nodes.

Neighbor Unreachability Detection

Communication with a neighbor may fail for a number of reasons. If the path (on the link) to the destination has failed, recovery may be possible. The recovery mechanism to invoke when a failure has been detected differs depending on whether the neighbor is also the final destination. If it is, the address resolution should be re-initiated. Otherwise, a different next hop should be selected. This falls under the next-hop determination algorithm (explained in "Next-Hop Determination" section), where two mechanisms can be used. Routers typically use their routing table, whereas hosts run the router selection algorithm (see the "Default Router Selection" section).

The neighbor unreachability detection (NUD), however, deals with detecting the failure. Reachability of a neighbor is obtained in two possible ways. The first method is a confirmation from an upper layer that communication is happening with this neighbor (for instance, received TCP packets acknowledging previously sent packets). The second method is the receipt of an NA as a response to an NS sent by the node looking for reachability confirmation. Any other methods, such as RAs, cannot be used to confirm reachability of a neighbor. A neighbor then remains reachable for a limited amount of time, unless new confirmations come in. If the confirmation is not received in a timely manner, the neighbor is considered unreachable, and recovery mechanisms take place. The complete state diagram for neighbor entries in the ND cache is detailed in the next section.

The State Machine for Reachability

The neighbor cache maintains a list of neighbors to which traffic has been sent recently. Figure 2-26 shows a state diagram of the neighbor cache.

Figure 2-26. ND Cache Entry State Diagram

In Figure 2-26, the following events will generate transition from one of the five states (INCOMPLETE, REACHABLE, DELAY, STALE, and PROBE):

• NA1 Receiving an NA with Solicited=0

• NA2 Receiving an NA with Solicited=1

• NA3 Receiving an NA with Solicited=1 and

  - Override=1 or

  - Override=0 and link-layer same as cached

• NA4 Receiving an NA with Solicited=1, Override=0, and link-layer different from cached

• NA5 Receiving an NA with Solicited=0, Override=1, and link-layer different from cached

• O Receiving other ND packets, such as NS, RS, RA, redirect, with link-layer different from cached

• S Sending packet

• T Timeout (Note that each state has a timer, started when entering the state.)

• Te Timeout with retries exhausted

• U Upper-layer reachability confirmation

The typical life of an entry is shown (in bold) in the state diagram of Figure 2-26. An entry is a mapping between an IPv6 address and a link-layer address. The entry is created INCOMPLETE (link-layer unknown), and an NS is sent to obtain the link-layer address. As soon as the response (NA) is received, the entry moves to REACHABLE state, and traffic can be forwarded. If the router sees no traffic for that neighbor for a certain period of time (typically 30 seconds), the entry moves to the STALE state. From there, it can either move back directly to REACHABLE (typically upon upper-layer reachability confirmation) or to DELAY (if a packet is to be sent to this neighbor), where a new NS is issued, or it can be deleted (in our example) after a certain amount of time in STALE (typically hours).

Autoconfiguration

The address autoconfiguration is used to automatically assign addresses to a host. Address autoconfiguration is specified in RFC 2462. It uses the NDP (specifically RAs) to obtain the prefix to build an address on, and again ND (specifically NS and NA messages) to test that the built address is not already in use. The default mechanism for autoconfiguration is stateless. Another mechanism, stateful, can be used and is specified in RFC 3315. Both mechanisms are described in Chapter 3, "Delivering IPv6 Unicast Services," in the section "Host IPv6 Address Provisioning."

Neighbor Discovery at a Glance

Table 2-14 summarizes ND information for quick reference.

Table 2-14. NDP at a Glance

Message Name	Goal	ICMP Code	Sender	Target	Options
Router solicitation (RS)	Prompt routers to send RA quickly	133	Nodes	All routers	SLLA[1]
Router Advertisement (RA)	Advertise: Default router On-link prefixes Reachable prefixes Oeration parameters	134	Routers	Sender of the RS or All nodes	SLLA MTU Prefix information Route information Advertisement interval Home agent information
Neighbor solicitation (NS)	Request the link-layer address of a target node	135	Nodes	Solicited node or Target node	SLLA
Neighbor advertisement (NA)	Respond to NA Advertise link-layer address changes	136	Nodes	Sender of the NS or All nodes	TLLA[2]
Redirect	Inform hosts of a better first hop	137	Routers	Host that triggered the redirect	TLLA Redirected header
Inverse neighbor solicitation (INS)	Request an IPv6 address corresponding to a link-layer address	141	Nodes	All nodes	SLLA[3] TLLA[3] MTU Source address list
Inverse neighbor advertisement (INA)	Respond to an INA	142	Nodes	Sender of the INS	SLLA[3] TLLA[3] Target address list[3] MTU

^[1] SLLA: Source link-layer address

^[2] TLLA: Target link-layer address

^[3] Option required

IPv6 is not limited, in the least, to the protocols reviewed in this chapter. However, this chapter covered the fundamental elements, to provide you with the tools to understand the most relevant differences between IPv6 and IPv4. With these tools in mind, the next chapters review IPv6 network services, all built "on top of" IPv6 addressing, ICMPv6, and the Neighbor Discovery Protocol.