MAC LayerL2

Multicast in Wi-Fi

Multicast Handling in 802.11 Networks - IEEE 802.11-2020 §11.2.1.7, RFC 4541 (IGMP snooping), RFC 4541bis8 rows#

Topic	Standard	Description	Problem / Risk	Solution / Best Practice	Wireshark / Debug
802.11 multicast TX rate	IEEE 802.11-2020 §11.2.1.7	Multicast/broadcast frames MUST be sent at one of the Basic Rates. Default basic rate = 1 Mbps (2.4 GHz) or 6 Mbps (5 GHz). No ACK, no retry.	At 1 Mbps, a 1500-byte multicast consumes ~12 ms of airtime - same as 300+ unicast frames at MCS 7. Multicast-heavy traffic (mDNS, SSDP, ARP) can dominate airtime.	1. Raise basic rates (6/12/24 Mbps min). 2. Enable multicast-to-unicast conversion. 3. Rate-limit multicast. 4. IGMP snooping to suppress unwanted groups.	wlan.da == 01:00:5e:xx:xx:xx (IPv4 mcast) wlan.da == 33:33:xx:xx:xx:xx (IPv6 mcast)
IGMP Snooping at AP	RFC 4541 (RFC 4541bis)	AP/WLC monitors IGMP Join/Leave messages. Only forwards multicast to STAs that have joined the group. Prevents flooding all STAs with all multicast.	Without IGMP snooping, ALL multicast is sent to ALL associated STAs at basic rate - massive airtime waste in large deployments.	Enable IGMP snooping on AP/WLC. Set IGMP query interval (125 s default). Track group memberships per STA per radio. Age-out stale memberships.	IGMP: ip.proto==2 in capture IGMP Query: igmp.type==0x11 IGMP Join: igmp.type==0x16 IGMP Leave: igmp.type==0x17
Multicast-to-Unicast Conversion	IEEE 802.11-2020 (AP implementation)	AP converts multicast frames to individual unicast frames for each subscribed STA. Each unicast uses highest negotiated rate, gets ACK, can be retransmitted.	Extra AP processing overhead. Does not scale to hundreds of STAs receiving same group (video multicast). Can increase total airtime if many subscribers.	Use for small groups (< 30 STAs). Avoid for large-scale video multicast. Combined with IGMP snooping for targeted delivery.	Monitor AP CPU utilization when enabling. Verify unicast delivery via wlan.da == [STA_MAC]
mDNS / Bonjour Proxying	RFC 6762 (mDNS) RFC 6763 (DNS-SD)	mDNS uses 224.0.0.251 (IPv4) or FF02::FB (IPv6) multicast. Sent at basic rate. Airporters, printers, Chromecast, Apple TV flood mDNS.	In large deployments, mDNS queries from hundreds of devices = severe airtime waste. Cross-VLAN discovery impossible without proxy.	mDNS proxy/repeater in AP: AP answers cached mDNS responses on behalf of devices. Cisco: mDNS gateway. Aruba: AirGroup. Enables cross-VLAN Bonjour.	wlan.da == 01:00:5e:00:00:fb udp.dstport == 5353
SSDP (UPnP)	IETF draft UPnP Forum	SSDP uses 239.255.255.250 UDP port 1900. Chromecast, smart TVs, Xbox constantly send SSDP M-SEARCH broadcasts. No IGMP control (UDP multicast below IGMP).	SSDP cannot be IGMP-snooped (no IGMP join for SSDP group). Rate-limiting is only option.	Rate-limit SSDP at AP: max 10-20 pkt/sec/client for SSDP. Block cross-VLAN SSDP (security + airtime).	wlan.da == 01:00:5e:7f:ff:fa udp.dstport == 1900
ARP / ND (IPv6) flooding	IEEE 802.11-2020 RFC 4861 (ND)	ARP broadcasts (FF:FF:FF:FF:FF:FF) and IPv6 Neighbor Discovery multicast sent at basic rate. Every STA wakes and processes every ARP.	In large networks, ARP rate can be hundreds/second. ARP for DHCP leases = particularly wasteful. IPv6 ND is worse - more frequent.	ARP proxy at AP: AP answers ARP on behalf of STAs (knows IP-MAC mapping from DHCP snooping). Proxy ND for IPv6. Suppress gratuitous ARPs.	wlan.da == ff:ff:ff:ff:ff:ff (ARP broadcast) arp.opcode==1 (ARP request)
DTIM & multicast buffering	IEEE 802.11-2020 §11.2.1.7	AP buffers all broadcast/multicast during DTIM periods. Sends buffered multicast after DTIM beacon. All STAs must wake at DTIM to receive.	High DTIM interval (e.g. DTIM=3 = every 307 ms) reduces wake events but delays multicast delivery. Low DTIM = more wake events = higher power draw.	DTIM 1: best for multicast delivery, worst for IoT battery life. DTIM 3-10: better for IoT, may delay mDNS/ARP responses slightly. TWT (802.11ax) enables per-device DTIM independence.	TIM IE in Beacon: wlan.tim DTIM period: wlan.tim.dtim_period
IPv6 Multicast in 802.11	RFC 4861 RFC 4862	IPv6 uses Neighbor Discovery (ND) multicast for ARP equivalent. More complex: Solicited-Node Multicast addresses (FF02::1:FFxx:xxxx), All-Nodes (FF02::1), All-Routers (FF02::2). Higher base rate of multicast traffic than IPv4.	IPv6 ND is significantly chattier than ARP. Every IPv6 STA generates Solicited-Node mcast address. MLDv2 snooping required (RFC 3810).	Enable MLDv2 snooping on AP. RA Guard (RFC 6105) to block rogue Router Advertisements. DHCPv6 snooping for address tracking.	wlan.da == 33:33:xx:xx:xx:xx (IPv6 mcast) icmpv6.type==133 (Router Solicitation) icmpv6.type==134 (Router Advertisement)

ADDITIONAL MULTICAST/BROADCAST TOPICS3 rows#

Topic	Standard	Description	Problem / Risk	Solution / Best Practice	Wireshark / Debug
Topic	Standard	Description	Problem / Risk	Solution / Best Practice	Wireshark / Debug
TWT and multicast delivery (802.11ax)	IEEE 802.11ax §26.2.37 TWT	In TWT (Target Wake Time), STAs sleep between TWT Service Periods. During sleep, AP buffers unicast frames. Broadcast/multicast: AP must still deliver during DTIM beacons regardless of TWT schedules.	TWT STAs sleeping during DTIM beacon will miss multicast delivery → multicast reliability drops for TWT-enabled IoT devices. Broadcast TWT requires all STAs to wake simultaneously - reduces individual power savings.	1. Use individual TWT for IoT STAs where multicast is not time-critical 2. Broadcast TWT: schedule TWT SP to include DTIM boundary 3. For real-time multicast (mDNS, ARP): use M-to-U conversion so delivery is per-STA unicast within each STA's TWT SP 4. For IoT: disable TWT if multicast data is required in real-time (e.g., push commands)	TWT SP boundaries: wlan.fc.type_subtype==8 beacon with TWT element DTIM period: wlan.tim.dtim_period STAs missing multicast: capture at STA level, compare with AP TX multicast frames
Proxy ARP for Wi-Fi (RFC 4389)	RFC 4389 IEEE 802.11-2020 §11.22.17	AP intercepts ARP requests from wireless STAs and responds on behalf of the target (if IP-MAC mapping known). Converts ARP broadcast (which would wake all sleeping STAs) into unicast reply from AP.	Without Proxy ARP: every ARP request is a broadcast that wakes all sleeping STAs and occupies airtime at basic rate. A 200-STA network can generate 500-1000 ARP broadcasts/minute during normal operation.	Enable Proxy ARP on AP/WLC. AP maintains IP-MAC table (from DHCP snooping or 802.11 management frames). Blocks ARP broadcast from reaching radio. Typical airtime saving: 5-15% in dense deployments. Essential for 802.11ah IoT where every broadcast wake costs battery.	ARP proxy: no ARP broadcast seen at radio level (wlan.da == ff:ff:ff:ff:ff:ff for ARP = proxy working). Verify via: tcpdump on wired side vs wireless side.