SV: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[Erik Nordmark]

[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 <lorenzo at google.com> writes:
>
>> On Thu, Jun 11, 2015 at 6:56 PM, Benedikt Stockebrand
>> <bs at 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
>