It is important to note that even if a destination's IPv6 address matches a prefix used on the link, or with the IPv6 address that a sending node has been configured with, it does not necessarily mean that the destination is actually on-link [8]. This kind of scenario can happen, for example, in network links having star topology and thus where each packet has to traverse through the central node. The on-link determination can only be made based on information received via Router Advertisements, ICMPv6 Redirects, or by some other explicit means such as by manual configuration. By default, nodes must assume that destinations are off-link. 3.4.4 Link-layer Address Resolution Before a node can send IPv6 packets over an underlying data link layer, a link layer address of the next hop entity needs to be known - assuming that the link has link-layer addresses in the first place. The node can use the Neighbor Solicitation message destined to a solicited node multicast address to request the owner of the destination IPv6 address to report its corresponding link-layer address in a response Neighbor Advertisement message. The resolving node originates a Neighbor Solicitation message with a source address set to any of the configured unicast addresses on the used outbound interface and a destination address set to the Solicited-Node multicast address of the to-be-resolved IPv6 address (see Section 3.2.4). Additionally, neighbors' addresses can be learned by receiving unsolicited Neighbor Advertisement or Router Advertisement messages. It is also possible to perform the Neighbor Discovery procedure in reverse: resolve a node's IPv6 addresses on the link when the link-layer address is already known. This procedure is called Inverse Neighbor Discovery and is specified in RFC 3122 [61]. Each IPv6 node maintains a Neighbor Cache that contains the list of its known neigh- bors, and the reachability state for each neighbor. The different reachability states are described in the following. INCOMPLETE: Neighbor Solicitation has been