r improves the router selection by introduction of preferences for default, and more specific, router selection as we discuss in Section 3.5.6 [68]. The on-link determination is done by matching the destination IPv6 address to the prefixes that node has received via Router Advertisements, assuming the prefixes are allowed to be used for on-link determination purposes (see Section 3.4.2). The link-local prefix fe80 : /10 and multicast prefixes are always considered to be on-link. Once the IPv6 address of the next hop is known, the node needs to find out is the corresponding link-layer address (for the case where the link layer has link layer addresses, see Section 3.6). This information is fetched from the Neighbor Cache (see Section 3.4.5), or if not available then with help of Neighbor Discovery procedures. After the link-layer address of the next-hop destination is available, it is stored into a Destination Cache. The Destination Cache exists to assist sending of the follow-up IPv6 packets to the same address - if an entry is found in the Destination Cache the Neighbor Cache checking and possible Neighbor Discovery procedures are avoided. The Destination Cache may be updated if ICMPv6 Redirect messages are received (see Section 3.4.8), and may also be updated if the NUD detects changes in link-layer addresses related to specific destinations (e.g. due to default router changes). A mere disconnection to the neighbor that has been used as next-hop does not cause cache entry flushing, as the entry may have information that is useful once the connectivity is regained. This information can be related, for example, to Path MTU, depending on the implementation. 3.4.7 Duplicate Address Detection Before any address can be assigned to an interface, a node must ensure the address is unique on the attached link [73]. This requirement applies equally to all unicast addresses including the link-local addresses. Before a node can check the uniqueness of an address, the node has to use MLD to join the 'Solicited-node multicast