Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[Tore Anderson]

* Lorenzo Colitti <lorenzo at google.com>

> On Wed, Jun 10, 2015 at 9:45 PM, Tore Anderson <tore at fud.no> wrote:
> 
> > > are *all* IPv6 packets blocked, or just multicast packets? I know
> > > that a number of devices will drop multicast IPv6 packets. This
> > > eventually blackholes connections because the device stops receiving
> > > RAs and thus loses its default route, but that can be worked around
> > > by setting long timers in the RA. I wasn't aware of devices dropping
> > > all inbound IPv6 packets, that really seems like a bad bug.
> >
> > AIUI, the maximum RA Lifetime is 9000 seconds. RFC 4861, section 6.2.1.
> 
> Except that 65535 works fine. :-)

Right.

There was another thing I thought of, though. We have a wireless
network with two redundant upstream routers that are not running a FHRP
like VRRP. Active/passive, since they do stateful inspection of
traffic. My solution to facilitate reasonably speedy failover from the
active to the passive router was to have a quite low RA lifetime, so
that the clients would quickly stop using a router that went offline.

Maybe I could instead leave the RA lifetime high, but set the reachable
time low, and depend on the client doing NUD. Would that work? In this
situation the clients would after a failover have two default routes,
where one has a next-hop that fails NUD. Do you know if clients in
general Do The Right Thing here and ignore the route that fails NUD?

In any case I get a problem when the primary router comes back online,
because then the clients end up with two default routes that both pass
NUD fine. I guess having the backup router send an few RAs with
lifetime=0 when it enters passive mode ought to handle that...

Also, lowering the reachable time isn't ideal on network with on-link
prefixes either as it'll impact client-client traffic too, not only
client-router. But that's probably not an issue on most WiFi
deployments I guess.

Tore