IPv6 wants 802.11 Flexible Multicast Service
draft-ietf-6man-ieee80211-fms-00

IPv6 Maintenance                                            D. Lamparter
Internet-Draft                                              NetDEF, Inc.
Intended status: Standards Track                       14 September 2025
Expires: 18 March 2026

              IPv6 wants 802.11 Flexible Multicast Service
                    draft-ietf-6man-ieee80211-fms-00

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 18 March 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Lamparter                 Expires 18 March 2026                 [Page 1]
Internet-Draft        draft-ietf-6man-ieee80211-fms       September 2025

   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.

Table of Contents

   1.  Issue . . . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Remedy: Flexible Multicast Service  . . . . . . . . . . . . .   2
   3.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Informative References  . . . . . . . . . . . . . . . . .   3
   Appendix A.  IETF procedural note . . . . . . . . . . . . . . . .   3
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   3

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.

Lamparter                 Expires 18 March 2026                 [Page 2]
Internet-Draft        draft-ietf-6man-ieee80211-fms       September 2025

   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>.

Appendix A.  IETF procedural note

   This document is not intended to advance to RFC; the only purpose is
   to aid the IETF consensus process to affirm the request.

Author's Address

   David 'equinox' Lamparter
   NetDEF, Inc.
   Leipzig
   Germany
   Email: equinox@diac24.net, equinox@opensourcerouting.org

Lamparter                 Expires 18 March 2026                 [Page 3]