IPv6 wants 802.11 Flexible Multicast Service

Internet-Draft	draft-equinox-6man-ieee80211-fms	July 2025
Lamparter	Expires 21 January 2026	[Page]

Abstract

IEEE 802.11 Flexible Multicast Service (FMS) addresses reliability issues in IPv6 due to aggressive powersave optimizations in 802.11 client devices.¶

The intent of this document is to collect consensus in the IETF 6man (IPv6 Maintenance) working group to request either/both the IEEE 802.11 Working Group and/or the Wifi Alliance's certification process to make implementing FMS a requirement.¶

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 21 January 2026.¶

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

1. Issue

For IPv6 to function correctly, hosts must receive traffic addressed to a set of multicast addresses. Specifically, router advertisements sent to ff02::1 (33:33:00:00:00:01) and address resolution traffic addressed to target-address-specific groups (cf. [IPV6NEIGH]). Losing some or all of this traffic makes IPv6 unreliable or entirely nonfunctional.¶

Receiving multicast traffic is power intensive for 802.11 clients since they need to wake up their receivers quite frequently even if there is no network activity. In the normal case, multicast traffic is sent after beacons, in 100ms intervals (the "DTIM interval" AP-side setting can affect this.)¶

In response, a number of 802.11 implementations have started to simply skip a chosen subset of these events, likely in violation of the 802.11 standard. As IPv4 is less reliant on broadcast/multicast, this frequently does not break IPv4. IPv6 connectivity, however, is adversely affected by the resulting loss of some multicast traffic.¶

2. Remedy: Flexible Multicast Service

The 802.11 Flexible Multicast Service protocol feature, introduced in 802.11v-2011, allows clients to explicitly request that some given multicast groups are buffered and delivered at less frequent intervals. The result is the same power savings as above, but since it is negotiated with the AP, the traffic loss is avoided.¶

Unfortunately, FMS is not mandatory to implement for 802.11 compliance and not required for Wifi Alliance certification. This document is to express IETF interest to push for FMS implementations.¶

3. References

3.1. Informative References

[IEEE80211]: IEEE 802, "IEEE Standard for Information Technology—Telecommunications and Information Exchange between Systems Local and Metropolitan Area Networks—Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", 2020.
[IPV6NEIGH]: Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/rfc/rfc4861>.