 bits of an IPv6 multicast address to fixed 33 : 33, hence creating a 48-bit multicast MAC address. An additional feature to this technique is defined in RFC 6085, which allows mapping of IPv6 multicast addresses to unicast Ethernet link-layer addresses in cases where the sending node knows that it is enough to send the message as a unicast to only one receiving device [117]. Obviously, for this to work, the receiving node must not drop multicast IPv6 packets that it has received on its unicast MAC address. Introduction to IPv6 3.6.3 Link Numbering As per the IPv6 addressing architecture, described in Section 3.1, each IPv6 interface typically has to have a link-local address (with few exceptions, e.g. with some tunneling solutions [160]). Then nodes on a link will always have at least a link-local addresses. This means that IPv6 does not have a concept of unnumbered links. Whether a link has addresses with a wider scope than link-local in use depends on the time and deployment scenario. When a link is without routers advertising global or ULA prefixes, the link-local addresses are the only means of communication. In some deployments inter-router links may not have other than link-local addresses by design, as for IPv6 packet forwarding link-local addresses are enough. Whenever a link has a prefix, the prefix is typically 64 bits long. In many link types, such as Ethernet, the prefix length of 64 bits is fixed [99]. Every now and then, mostly from the old habit of extreme IPv4 address conservation needs, people tend to propose longer than 64-bit prefixes for scenarios where only few nodes are using the prefix. In IPv6, addresses are SO plentiful that such extreme conservation is not necessary, especially when it comes with increased complexity. However, there are also other reasons why the prefix length is best kept at the current state. Having a 64-bit prefix on all link types allows simplification of IPv6 stack implementations, and also ensures that features such as privacy addresses (see Section 3.5.5) and Nei