IPv6 issues with 802.11 multicast reliability remain

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

2.1. 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. [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 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.¶

2.2. mDNS (and other multicast) roaming issues

A related but distinct issue in the reliability of IPv6 multicast exists in delivery of mDNS [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 [MLDv2].¶

If the access point or another device in the network (802.11 DS) between access points performs MLD snooping [MLDsnoop], 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.¶

2.3. General notes

The issues discussed here are not new and have been discussed previously, e.g. in RFC 9119 [MCAST802]. 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.¶

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

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

4.1. 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 [IPV6MC_L2UC] 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 [MCAST802] 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.¶

4.2. 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 [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.¶

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

4.4. 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 [MLDv2] join state of its associated clients (MLD snooping [MLDsnoop]). 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 [MLDv1] and MLDv2 [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.¶

4.5. 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 [IPV6MC_L2UC]) 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).¶

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

4.7. 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).¶