3.9 KiB
Address resolution
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). 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. 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, 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, also known as neighbor discovery (ND), 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. 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.
These are the essentials of address resolution; readers who want more detail should consult RFC4861.
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 and in Section 4.2.1 of RFC5757. As an absolute minimum, the WiFi infrastructure switches in a large network need to support MLD snooping as explained in 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. 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, 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.
A summary of the issues and complications of neighbor discovery on wireless networks in general (not just WiFi) can be found in this draft.