NetDEF, Inc.

Leipzig Germany equinox@diac24.net equinox@opensourcerouting.org

Google

furry13@gmail.com

Internet IPv6 Maintenance IPv6 802.11 multicast dtim dms fms For the IPv6 protocol stack, while IEEE 802.11 wireless networks can on a first abstraction be considered functionally identical to wired IEEE 802 networks, there are issues regarding reliability and survivability of multicast traffic. The existence of these issues has been known for some time. This document is to state that they are still being experienced, and summarize some previous and new approaches. Additionally, this document serves to collect consensus in the IETF process to make both the IEEE and Wi-Fi Alliance aware of these issues and request they be included in consideration for future development. 802.11 Directed Multicast Service and Flexible Multicast Service are noted as existing protocol features that may warrant more consideration. However, other solutions in that space may be more appropriate and are left to the expertise of the IEEE and Wi-Fi Alliance.

Terminology The following terms reference definitions or items in IEEE 802.11. Please note any context beyond the acronym expansion is given purely to aid understanding, may contain errors and truncations, and is no replacement for sufficient knowledge of the IEEE 802.11 standards.

AP

Access Point. A single physical device may provide multiple instances of this function even on a single radio interface.

BSS

Basic Service Set. The definition of this term is relatively complex due to e.g. 802.11 mesh functionality. In the context of this document, which involves an AP, the set of stations and AP that are "joined" in 802.11 with each other.

client

non-access-point (non-AP) station (STA). IEEE 802.11 does not use "client" as a term, it is used here due to ease of understanding in IETF context and being colloquially common.

DMS

Directed Multicast Service

DS

Distribution System. The interconnect between multiple BSS forming a single ESS. May exist within a physical device (between multiple AP functions) or between devices. Generally, IEEE 802.3 Ethernet, possibly encapsulated/tunneled.

DTIM Period

Delivery Traffic Indication Map Period. An integer value, multiplied with the beacon interval to arrive at the DTIM interval. Multicast traffic, in the absence of other factors, is delivered once per DTIM interval. Signaled by the AP in beacons for a BSS.

ESS

Extended Service Set. One or more BSS that appears functionally as the same BSS to any client connected with any of them.

FMS

Flexible Multicast Service

GCR

GroupCast with Retry

MPDU

medium access control (MAC) protocol data unit (PDU). IEEE 802.11 specific, "down layer" data unit. Also called MAC frame in 802.11. An aggregated variant (A-MPDU) exists.

MSDU

medium access control (MAC) service data unit (SDU). More generic, "up layer" data unit that may be carried over a DS between APs, and may take the form of an Ethernet frame in that case. An aggregated variant (A-MSDU) exists in 802.11 context.

roaming

basic service set (BSS) transition; a client switching its association from one BSS to another BSS within the same ESS. The term "roaming" is present in IEEE 802.11 but not as an exclusive, unambiguous reference to specifically this kind of transition.

Additionally, the following terms are used:

Frame

Data unit of the layer ("2", MAC) carrying IP and likely containing additional outer headers/encapsulation of an IP header.

Host

Participant in IPv6 on a link, regarding a single interface with a single link-layer address. In IPv6, will almost always have multiple IPv6 addresses even in the same scope. Since IP forwarding is not relevant to the considerations here, an IP router consists of multiple hosts for the purposes of this document. The same applies to other devices with multiple interfaces. The link-layer address is generally expected to be unique for a host, though there are some poorly defined situations where it is shared (e.g. proxy ND, repeaters) that require context-specific consideration.

Packet

Data unit of IP ("layer 3") without further outer headers or encapsulation.

RA

IPv6 Router Advertisement

Requirements Language This document does not specify new protocol behavior, it only outlines implementation choices and highlights some consequences. Therefore, no specific requirements language is used in this document. Some approaches outlined in this document may benefit from a more rigorous description; this is out of scope for the time being.

Problem Statement

Fundamental IPv6 reliability 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. ). 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 period AP-side setting defines this.) In response, a number of 802.11 implementations have started to simply skip a chosen subset of these events, without any other entity in the network being aware of this. Whether this conforms to the 802.11 standard is beyond the purview of the IETF and the insight of the authors of this document. 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. Albeit somewhat difficult to gather data for, there is a sufficient amount of input being heard at the IETF that IPv6 is in fact suffering from issues due to multicast reliability. Enterprise Wi-Fi networks (involving a "controller") seem largely unaffected.

mDNS (and other multicast) roaming issues A related but distinct issue in the reliability of IPv6 multicast exists in delivery of mDNS multicast traffic after an 802.11 client device roams to another 802.11 access point. mDNS uses the IPv6 multicast group ff02::fb and the IPv6 host will report that group as joined using MLD. If the access point or another device in the network (802.11 DS) between access points performs MLD snooping, these devices will be maintaining a table for each multicast group, tracking joins based on either (link-local) IPv6 addresses, MAC addresses or ports (possibly association IDs in 802.11). If additionally the IPv6 end host stack is unaware of 802.11 roaming events, or hasn't connected them into the MLD implementation, it will not re-report the group as joined by sending MLD until either queried again or the mDNS component leaves and rejoins the group. A MLD querier is necessary for MLD snooping operation, and will dictate timing. With typical MLD querier timers, this results in a period of a few seconds to minutes where MLD snooping state does not reflect the joined group. mDNS then receives no advertisements, service discovery does not work and a poor user experience results. There is also an unfortunate crosslinking of this issue with attempted fixes to general IPv6 reliability: multicast to unicast conversion requires the AP to be aware of which clients are joined to a given group. The means for the AP to acquire this data is MLD snooping. Attempts to fix general IPv6 reliability by further use of multicast to unicast conversion may thus have worsened mDNS issues. The considerations in this section also apply to other protocols using multicast, but were primarily reported regarding mDNS. There is currently no standardized protocol to transfer MLD state between devices performing MLD snooping.

General notes The issues discussed here are not new and have been discussed previously, e.g. in RFC 9119. The actual situation is slowly shifting, but is in general observed to persist in some shape. Some of the approaches described in this document are already in use. However, they do not seem to be sufficient to fully address this. It is expressly suggested here that multiple of the outlined approaches may need to be taken simultaneously.

Operational approaches

Increasing DTIM period The DTIM period is generally an operator accessible setting on their 802.11 installation, though not all devices (particularly intended for home use) may expose it. Raising the DTIM period, e.g. to 5, is reported to alleviate the general IPv6 reliability issues, since client devices seem to consider this as sufficiently power efficient and not perform further aggressive multicast dropping. Values larger than 5 may interfere with IPv4 Proxy ARP functions, some of which use a 600ms delay by default. Larger values also result in higher latency on multicast delivery, which will be visible to end users as e.g. delay on mDNS discovery.

Increasing IPv6 RA frequency Since the power save behavior at issue results in a roughly random drop of some percentage of multicast traffic (i.e. assuming it does not synchronize with a device's regular extra drop periods), it is possible to achieve a higher delivery chance for IPv6 router advertisements by sending them more frequently or in bursts. This is also normally available to the operator to tune, though again not necessarily on devices intended for home use. This approach, if seen at large, is likely to result in a "race to the bottom" where networks send more and more multicast traffic, and devices drop more and more of that traffic. If this approach is intentionally added to an RA sender implementation, timers need to be chosen carefully to ensure there is sufficient variance in RA transmission timers at the sub-second level to avoid synchronizing with an 802.11 client implementing aggressive power-save by sleeping through a given fraction of DTIM periods.

Implementation approaches

Directed Multicast Service The 802.11 Directed Multicast Service protocol feature, introduced in 802.11v-2011, enables clients to negotiate with the AP to receive specific multicast groups as unicast traffic on the underlying 802.11 layers. The AP then applies the same power save mechanisms as with unicast traffic, i.e. buffers it and delivers it when the client signals to the AP that it is awake. There is a notable detail distinction when DMS is used, in contrast with opportunistic AP-side multicast-to-unicast conversion. The protocol layers in 802.11 are such that an IPv6 (or other) frame passing into 802.11 can have its destination MAC address be kept unchanged as multicast in its MPDU, and get wrapped in an 802.11 MSDU with a different unicast destination (receiver) address. Opportunistic conversion generally changes the MPDU destination address instead, which then propagates into the MSDU. While visible to the client on receiving such frames (and thus possibly impacting other protocols), this distinction is harmless to IPv6 due to RFC 6085 behavior. RFC 6085 is understood to be widely implemented. Implementing DMS on the client side requires the IPv6 stack to specify a frame classifier for use in the TCLAS element. There are multiple choices that would match IPv6 multicast RAs (or other neighbor discovery traffic), in particular it could match on either the IPv6 group address or the layer 2 multicast address. Making this choice consistent may be beneficial to AP compatibility or resource usage. Unfortunately, DMS is not mandatory to implement for 802.11 compliance and not required for Wi-Fi Alliance certification. However, contrasted against RFC 9119 stating in 2021 that "DMS is not currently implemented in products", there is a change in that some Enterprise AP products now list DMS available. No client is known to the authors to be implementing DMS yet, but some available AP side support (even if in systems that already don't see much of these issues) at least breaks a "chicken and egg" problem in getting client implementations.

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. (It can also negotiate different radio transmission rates, but this is of little concern here.) The result is the same power savings as above, but since it is negotiated with the AP, the traffic loss is avoided. FMS uses the same TCLAS element as DMS. The paragraph on classifier choice above applies here as well. FMS and DMS can be implemented simultaneously, in either case it is the client that has to initiate a request. FMS has a (currently theoretical) advantage in that actual radio multicast may remain available as a networking tool to use, e.g. for MC-QUIC. This is of course a moot point if it doesn't work reliably enough. Unfortunately, as with DMS, FMS is not mandatory to implement for 802.11 compliance and not required for Wi-Fi Alliance certification. Unlike DMS, the authors are not aware of any FMS implementations.

GroupCast with Retries GroupCast with Retries (GCR) may also work to alleviate some of the issues described here. It performs either unsolicited retries, or can use a block acknowledgment mechanism to determine necessary retransmissions. However, since it operates at a lower level than any other approach listed in this document, GCR is believed to be the most involved (and thus unlikely to succeed). Due to this, GCR is receiving relatively little consideration in this document.

Opportunistic AP-side Multicast to Unicast conversion In a manner quite similar to DMS, it is possible for the AP to convert multicast traffic to unicast by tracking the MLD join state of its associated clients (MLD snooping). This works without the client's cooperation or even awareness. The actual frames seen on the wireless medium with this approach are commonly slightly different from the ones seen if DMS were in use. Refer to the paragraph on MSDU and MPDU destination addresses in the DMS section. An issue with this approach, already alluded to in the mDNS problem description, is that there is no standardized way to transfer MLD snooping state between devices. Since this behavior is an AP implementation choice, it is sensible for the AP to also compensate for this by sending an MLD general query, ideally unicast to the roaming client. Additionally, clients' IPv6 stacks could proactively send MLD reports when they detect a roaming event has happened. A known implementation insufficiency with this approach is that MLD snooping is commonly an Ethernet bridge function, and ignores (builds no) state for ff02::1 since all hosts are intended to receive multicast traffic to that address by specification. The multicast to unicast conversion function then, rather than using unicast to all associated clients, leaves packets to this address unmodified as multicast. RAs are sent to this address, and get lost. (The Linux kernel, which forms the basis for a good number of AP products, does this exactly this in all current mainline versions.) Unfortunately, MLD snooping is also known to be somewhat fragile regarding correct configuration of the remainder of the network. A frequent cause of this is intermixing of MLDv1 and MLDv2, and the MLDv1 duplicate report suppression behavior (refer to section A.2. of RFC9777 for further detail). Multiple MLD queriers on a network also increase the risk for MLD snooping misbehavior, meshing with issues regarding "multicast router port" configuration.

Opportunistic Unicast transmission by Router Apart from the AP performing multicast to unicast conversion on packets already in flight, router(s) can send RAs as either unicast packets (link-local IPv6 destination address) or unicast frames (multicast IPv6 destination address, but unicast layer 2 destination, i.e. RFC 6085) immediately on transmission. The latter approach is believed to result in fewer compatibility issues. Performing this operation requires the router(s) to be aware of all IPv6 hosts - or at least all 802.11 IPv6 hosts - on a link. If there is only a single router, co-located with the (only) AP function(s) for an ESS, this could utilize information from the 802.11 layer. However, this stops working if more APs (or routers) are present or added to the ESS later. Alternatively, the router(s) would need to keep track of all hosts on the link (likely unable to distinguish 802.11 devices from others).

AP-side IPv6 RA repetition Beyond configuration or implementation on a router, an AP might theoretically also implement this by buffering received RAs and retransmitting them multiple times only onto its BSS side. This is anticipated to be very error prone since there may be multiple routers, each sending multiple RAs, choosing arbitrarily to distribute RA contents across them. There is a high risk this will lead to APs accidentally retaining stale information, as well as not correctly supporting less common scenarios (e.g. multiple routers) or future extensions. This approach is listed here for completeness, in particular since the AP is in the unique position to align repeated RAs with the DTIM period. No recommendation is made for or against this approach, though there is certainly a need to exercise a lot of care in testing.

Increased use of Router Solicitations by the client An IPv6 host might attempt to address the issue of losing IPv6 on after lost multicast RAs by sending Router Solicitations on detecting the issue. This is both unlikely to address the issue as well as counter to the basic design of IPv6 Router Advertisements. RAs were designed as a push-based mechanism, so that network changes can propagate quickly to clients. Additionally, section 6.2.6. of RFC4861 explicitly calls out that routers would commonly respond to these solicitations with multicast responses, which would then again be affected by multicast delivery reliability. Similar to the previous section, this approach is listed for completeness, and rather advised against. There is no normative statement here since it is ultimately up to the client's IPv6 stack to use additional IPv6 router solicitations (or not).

Wireless extenders and bridges The existence of "repeaters", which connect behind a single 802.11 client multiple hosts through some further wired or wireless network, additionally complicates the matters described here. Further, 802.11 has the concept of 4-address frames applicable to this kind of device, but to avoid compatibility issues they may also utilize 3-address frames and "MAC NAT" or Proxy ND/ARP. Actual behavior on this is often outside applicable specifications' scope, or even straight up in conflict. This document defers discussing expected or recommended behavior for these devices for a later document, hopefully with more experience which approaches are effective on the more limited problem outlined here.

Request to IEEE and Wi-Fi Alliance The IETF (in particular the 6man working group) would like to make aware and involve the IEEE and Wi-Fi Alliance on the issues described in this document. In particular:

• is the issue of lost multicast traffic due to uncoordinated power-save sleep mechanisms known, and what is the perspective on it? Aside from practical reality, is the behavior exhibited by these client devices something that must be expected within 802.11 specifications and Wi-Fi Alliance certifications, and dealt with?
• Is there any input on the various approaches outlined in this document?
• 802.11 FMS seems to have been expressly designed to deliver the power save gains on multicast reception without causing this issue. It does not seem to be implemented widely. Is this observation correct, and is there background on it?
• There was some input that 802.11 DMS is more likely to be both practically useful as well as successful in addressing this issue. It seems to suffer from the some lack of implementations, though less so than FMS. Is this view roughly correct, and is there context on it?
• Is it appropriate to call 802.11 GCR the most complex of the approaches listed here, and should it be considered less likely to be practically useful here?
• If there are technical issues with DMS, FMS, or GCR, is there ongoing work to fix them? Is there other related existing or development standards work that should be taken into account for this issue?
• If DMS or FMS are to be used to address this issue, is there any comment on the choices regarding the TCLAS element?
• Assuming there aren't technical issues preventing it, would the Wi-Fi Alliance be able to include these considerations in future certification requirements, e.g. require some of support for one or more of the protocol solutions?

Privacy and Security Considerations Changing some 802.11 traffic from multicast transmission to unicast results in different encryption mechanisms applying. The unicast mechanisms have better privacy and security expectations. Battery depletion due to wasted power is a security concern in the availability sense. It may even be a safety concern when considering emergency services. Having routers keep track of all IPv6 hosts on a link has a minor impact on privacy. Routers will generally have most hosts in their neighbor table out of necessity. The same information would be kept further.

IANA Considerations This document has no IANA considerations.

The mDNS issues described in this document were brought to attention by Ted Lemon. Thanks to János Farkas, Emily Kooistra, Pascal Thubert, and Éric Vyncke for their input on this document. Additionally, Thanks to Suresh Krishnan, Mirja Kühlewind and Warren Kumari for their assistance and explanations regarding liaison processes.

References Informative References IEEE 802

October 2026 [-01 after renaming]: restructure the entire document. September 2026 [-02]: this document is being renamed from "ieee80211-fms" to "ieee80211-dms", which may result with some document upload oddity

IETF procedural note (to be removed before publishing) There was a comment here earlier that this document is not intended to advance to RFC. After some consideration, the intent is now to progress it to RFC, though as a document with no requirements language. However, even in the absence of such language, the concern here is the specification interface between 802.11 and IPv6, hence this document is kept in 6man (as opposed to v6ops). (Put plainly, making e.g. the IPv6 stack call the appropriate DMS or FMS primitives is not an operational consideration.)