[Catching up on email] Benedikt,
Note that https://tools.ietf.org/html/draft-ietf-6man-rs-refresh-00 is an attempt at addressing refresh without a multicast RA every 3 seconds, by only having the host do this refresh when it knows that the router doesn't default to multicasting solicited RAs.
The key use case are hosts that sleep on a schedule i.e. that do not wake for any packets, but yet need to be able to quickly get connectivity when they do wake up. Whether RS refresh is useful vs. harmful for devices that wake up for packets is a source of discussion in the 6MAN WG.
Regards, Erik On 6/13/15 10:25 AM, Benedikt Stockebrand wrote:
Hi Lorenzo and list, Lorenzo Colitti <lore...@google.com> writes:On Thu, Jun 11, 2015 at 6:56 PM, Benedikt Stockebrand <b...@stepladder-it.com> wrote: they should at least send an RS when they wake up and ensure their configuration is still up to date.That sounds like a bad idea. If devices send an RS every time the user turns the screen on, and the router responds with a multicast RA, any medium-size network or larger will have multicast RAs flying around every 3 seconds and killing everyone's battery.not quite; as Eric pointed out, RAs may be sent unicast. While this was originally intended for underlying NBMA link layers, it does make kind of sense in this context, too. The downside with this however is that it makes monitoring for rogue routers more difficult again (using tools like ramond) at least in switched networks. But aside from that, my wording was imprecise. Make that "send an RS when they wake up and they determine they have been offline long enough", for "long enough" being somewhat in the order of "such that the router lifetime expired" or similar. Figuring out the exact details is left as an excercise to the so inclined reader:-) Cheers, Benedikt
