When an IPv6 node "A" becomes aware of the IPv6 address of another node "B", and requires to send a packet to B, it must first determine whether B is directly connected to one of the same links as A. If not, it will need to send the packet to a router (see [Routing](Routing.md)). This is known as "on-link determination". The simplest case is when the address of B is a link local address as described in [Addresses](Addresses.md). In that case, it is necessarily on-link. In cases where B has a routeable address, A can determine whether it is on-link by consulting information received from Router Advertisement (RA) messages. This process is well described in [RFC4861](https://www.rfc-editor.org/info/rfc4861), so is not repeated here.
When A has determined that B's address is on-link, and in the process determined which interface that link is connected to, it starts address resolution by multicasting a Neighbor Solicitation message via that interface to the link local all-nodes multicast address, which is ```ff02::1```. Neighbor Solicitation is a specific form of ICMPv6 message; ICMPv6 is defined in [RFC8200](https://www.rfc-editor.org/info/rfc8200). Since this is a link local multicast, such messages never escape the local link.
All IPv6 nodes **MUST** monitor multicasts sent to ```ff02::1```. When B receives the Neighbor Solicitation from A, it replies with a Neighbor Advertisement message, sent unicast to A's link local address. A will then decode that message to obtain B's Layer 2 address (typically an IEEE MAC address), and will record the information in its Neighbor Cache for future use. At that point, A has all the information it needs to send packets to B.
This mechanism works well on a small scale, and it was designed with full knowledge of the "ARP storms" experienced on large bridged Ethernets running IPv4. However, it can cause significant multicast overloads on large bridged WiFi networks. Multicast is badly supported by large WiFi networks, as discussed in [RFC9119](https://www.rfc-editor.org/info/rfc9119) and in Section 4.2.1 of [RFC5757](https://www.rfc-editor.org/info/rfc5757). As an absolute minimum, the WiFi infrastructure switches in a large network need to support *MLD snooping* as explained in [RFC4541](https://www.rfc-editor.org/info/rfc4541). "MLD" means "Multicast Listener Discovery" and is the mechanism used by IPv6 routers to identify which nodes require to receive packets sent to a given multicast address. Version 2 of MLD is specified by [RFC3810](https://www.rfc-editor.org/info/rfc3810). Of course, all IPv6 nodes must join the ```ff02::1``` multicast group, so MLD snooping does not avoid the scaling problem, but at least it suppresses multicasts on WiFi segments that do not need them.
Operational issues with Neighbor Discovery and wireless multicast have been analyzed in the past ([RFC6583](https://www.rfc-editor.org/info/rfc6583), [RFC6636](https://www.rfc-editor.org/info/rfc6636)), but it remains the case that very large Wifi networks (such as the IETF builds several times a year for its plenary meetings) are subject to significant multicast overloads. In practice, this causes the WiFi switches to arbitrarily throttle the rate of multicasting, so Neighbor Discovery proceeds very slowly. It is **strongly** recommended to limit the size of wireless subnets as much as practicable.
