Solicited-node multicast address

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

A Solicited-Node multicast address is an IPv6 multicast address valid within the local-link (e.g. an Ethernet segment or a Frame Relay cloud). Every IPv6 host will have at least one such address per interface. Solicited-Node multicast addresses are used in Neighbor Discovery Protocol for obtaining the layer 2 link-layer addresses of other nodes.[1]

A Solicited-Node multicast address is created by taking the last 24 bits of a unicast or anycast address and appending them to the prefix ff02::1:ff00:0/104.[2] It is important to realize that we have taken 104 bits from the address, so that the last byte of the penultimate field 00 is not used in the prefix. Look at the examples below where the last 24 bits of the multicast address begin after ff.

A host is required to join a Solicited-Node multicast group for each of its configured unicast or anycast addresses.

Example: If we have an interface with the IP address fe80::2aa:ff:fe28:9c5a the associated Solicited-Node multicast address is ff02::1:ff28:9c5a. So we must join to the multicast group represented by this address.

Working Example[edit]

Assume a host needs to make a local delivery to another host on the local network, and the target host has an IPv6 address of fe80::2aa:ff:fe28:9c5a (as in Example 2 above). In order to make a Layer-2 (e.g. Ethernet) delivery, it needs to know the target host's hardware address (e.g. "Ethernet MAC address"). But in order to do this, it must first determine which hardware address to send it to. To do this, an IPv6 host will construct the Solicited-node Multicast Address related to the target address.

We can see this clearly if we look at an example using the equivalent uncompressed IPv6 address.

fe80::2aa:ff:fe28:9c5a                      Target address (compressed notation)
fe80:0000:0000:0000:02aa:00ff:fe28:9c5a     Target address (uncompressed notation)
                                -- ----     the last 24-bits
ff02::1:ff00:0/104                          Solicited-node Multicast Address prefix
ff02:0000:0000:0000:0000:0001:ff00:0000/104 (uncompressed)
---- ---- ---- ---- ---- ---- --            The first 104 bits
ff02:0000:0000:0000:0000:0001:ff28:9c5a     Result
ff02::1:ff28:9c5a                           Result (compressed notation)

The result of this process is the IPv6 link-local solicited node multicast address that the Neighbor Solicitation packet is sent to.

Efficiency Compared to IPv4 and ARP[edit]

Solicited-node multicast addresses are used with IPv6 neighbor discovery to provide the same function as the Address Resolution Protocol (ARP) in IPv4. ARP uses broadcasts to send an ARP request to the broadcast MAC address FF:FF:FF:FF:FF:FF, which is received by all stations on the local link, although only one station—the one being queried—would need to respond. The other stations still have to process and discard the request. This interruption can cause problems on networks if the amount of broadcast traffic becomes excessive. Devices, such as embedded print servers, might not be able to cope with the amount of traffic they are processing, and fail to operate in a timely manner.

Because a solicited-node multicast address is a function of the last 24-bits of an IPv6 unicast (or anycast) address, the number of hosts that are subscribed to each solicited-node multicast address is very small. This number would typically be one, but there could be a few because the mapping function is not a 1:1 mapping. This means that a host should not need to be interrupted as often to service neighbor solicitation requests, compared to ARP in IPv4.

However, to prevent any intervening Ethernet switches from flooding the multicast frames out of all switch ports, which turns the traffic profile into something more like broadcast, intermediate switches should implement MLD snooping, which would allow them to send traffic that is addressed to a solicited-node multicast address (or any other multicast address) to be sent out only on the ports that lead to stations that have subscribed to receive that traffic.


  1. ^ T. Narten; E. Nordmark; W. Simpson; H. Holiman (September 2007). Neighbor Discovery for IP version 6 (IPv6). Network Working Group. doi:10.17487/RFC4861. RFC 4861.
  2. ^ R. Hinden; S. Deering (February 2006). IP Version 6 Addressing Architecture. Network Working Group. doi:10.17487/RFC4291. RFC 4291. Updated by: RFC 5952, RFC 6052, RFC 7136, RFC 7346, RFC 7371, RFC 8064.