[IPv6]Re: Suggested RA lifetime defaults

[Tim Chown <[e-mail]>]

Beaconing Maciej’s email…

On 26/03/2025, 18:36, "Maciej Żenczykowski" <[e-mail]> wrote:

Here's how things currently work (to the best of my knowledge).

Wifi fundamentally has two types of frames.
Frames to all - encrypted with a group key (known to all clients).
Used for multicast/broadcast, I believe this is usually sent at
low(er) data rate so all clients get it.  There is *no* confirmation
of delivery.
Frames to a single client - encrypted with a client key.  Used for
unicast, sent at the highest possible rate for the given client.
There *is* confirmation of delivery (and retries).

NOTE: *some* good access points do b/mcast to unicast conversion, and
send everything as unicast.  This is much more common in enterprise
wifi gear.  This solves the mcast loss problem entirely.

The WiFi access point periodically broadcasts wifi beacons.  Usually
the interval is 100ms (but it might be configurable, it is in
hostapd/openwrt for example).
There are two types of these beacons: with and without multi/broadcast.
Usually it will send N-1 mcast-less beacon frames, and then 1
mcast-yes beacon frame (and repeat).
N is the 'dtim period/interval' and is a feature of the access point
(it may be configurable, on a good access point it will be).
Many times N is just 1 (ie. all beacons are potentially
mcast-carrying), opensource hostapd/openwrt defaults to 2, my personal
experience is 6 works better/best.

The beacons include information about which next beacon will have
mcast (ie. there's a counting down integer in them, and when it hits 0
you get mcast)

I think the m/bcast beacons just include the m/bcast frames directly
in them (or directly after them?).
Anyway, to receive 100% of m/bcast you have to listen to each of these
mcast-yes beacons.
If you miss them you simply get m/bcast packet loss.

The beacons (I think all of them) somehow include information about
which clients have pending unicast frames.
When a client notices a beacon informing it there is pending unicast
it asks the AP to transmit them, receives them, and confirms delivery.
In practice this means unicast delivery is reliable, provided the AP's
buffers (presumably per client) don't overflow.

The higher the dtim period, the longer mcast/bcast traffic gets
delayed by the AP (since it can only be sent along with the mcast-yes
beacon).
This increases m/bcast latency, but it doesn't affect unicast latency.
Since m/bcast is primarily (almost exclusively) used for discovery
(and net config), its latency doesn't really matter.
(at least so long as it doesn't go above around a second, which can
cause ARP timeouts/retransmits for example)

Receiving wifi beacons costs power, the wifi chip has to periodically
wake up enough to decode the airwaves, and parse the beacon and see if
it needs to do anything (ie. receive mcast or ucast) or not.
On battery powered devices, power draw matters.  Being able to keep
the entire wifi chip sleeping for longer is better.
[Note: we're *not* talking about OS suspend here, we're talking about
suspending parts of the digital signal processing pipeline inside of
the wifi chip itself]

Ideally devices (or rather mobile/battery optimized wifi chips) don't
want to have to wake up every 100ms for every beacon.
As such, if the device is in some low power state (inactive phone
sitting on your desk or in your pocket), then the wifi chip is also
instructed to try to minimize power.
Obviously, there is no need to listen to mcast-less beacons, you can
simply wake up every N*100ms and only check the mcast-yes beacons.
Then if needed, decode the following m/bcast frames, check the
ucast-for-you flag, and if present, ask the access point to transmit
those.

This is why a high dtim period is good for power draw.

Here we start getting into vendor specific stuff.  Since most wifi APs
have dtim period of 1, and waking up every 100ms to listen to
mcast-yes beacons is not desirable, many vendors implement hacks.
The most common of these is introducing a 'dtim multiplier' M.
Instead of listening to all mcast-yes beacons, you only listen to
every M-th one.
This causes you to lose M-1 mcast-yes beacons for every 1 you receive,
and thus also causes m/bcast loss (simply put M-1 / M packet loss).
For IPv4, since m/bcast is *mostly* used by ARP, and that simply gets
retried and/or extensively cached, you can get away with *very* high
bcast packet loss and ipv4 will still work.
Devices have been known to run with M=9 or even 10 on N=1 wifi networks.

[Note that usually if the device wakes up, ie. you're actively using
it, screen is on, device in your hand, then M gets set/clamped down to
1]

Since you don't want to delay things by more than ~1 second, usually
there is some automatic limitation of M, so that beacon interval
(100ms) * dtim period/interval (N) * dtim multiplier (M) < ~1s.
[I believe on most google pixel phone wifi chips the precise value of
that ~1s is approx 1.11s, I am surprised it is so high, I would have
expected 900ms - 1s, but oh well...]

Obviously the higher the WiFi access points dtim period (N), the lower
the maximum Wifi client's dtim multiplier (M).
In particular, with 100ms beacons, if N>=6 then M must be 1.  This is
why I recommend/use a dtim interval of 6 on my own access points.

IPv6 is more susceptible to mcast loss than IPv4 is.  IPv4 mostly
needs incoming broadcast ARP requests to work, and that is usually
tried 3 times and/or heavily cached by the router.
While IPv6 needs the periodic RAs to refresh ip/route information -
and there is no automatic retry (ie. no send RS near ip address /
default route expiration).

I believe on IPv6 enabled networks, in practice M is capped to 2 (for
a 50% loss rate).  I don't know if all devices do this, but if M>2 you
basically can't really expect v6 to work...
So a device may run with M=9 on an N=1 network, and switch to M=2 when
it detects RAs.

Ideally wifi access points would just get higher N values, and M could
just always be 1 and everything would just work...
But that simply isn't the case nowadays...

Let me know if something is unclear, getting tired of writing this
wall of text ;-)

- Maciej
(I'm not on the mailing lists, so that'll bounce and Bob Hinden
approves my last 2 messages but said he won't approve another unless I
sign up, and I haven't yet, so...)