Samsung phones block WiFi IPv6 when sleeping, delayed notifications
Lorenzo Colitti
lorenzo at google.com
Fri Jun 12 10:11:15 CEST 2015
On Fri, Jun 12, 2015 at 4:54 PM, Ole Troan <otroan at employees.org> wrote:
> > 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.
>
> then it turns into a silly race… the network is forced to send RAs at very
> high frequency, because hosts that wake up with expired routers, don’t RS…
>
No, that's not what it turns into.
The right way to do this is for the network to send periodic RAs at a
reasonable interval - say, 10 minutes - and for the hosts to wake up when
RAs arrive, process them, and go back to sleep.
This is already how things work. Wifi chipsets already have to wake up
every few tens/hundred of milliseconds ms to listen for multicast packets.
Hosts already need to wake up when they receive unicast packets (well - on
some manufacturers, only unicast IPv4 packets :-)), because people want to
receive chat messages when the device is asleep. Hosts also need to reply
when they receive broadcast ARP - because otherwise the link routers can't
to talk to them, and they users can't receive chat messages.
There is plenty of battery power even on a watch to wake the CPU up once
every 10 minutes - in fact, it's probably awake much more often than that
already
The only thing required to make this work well is that if a network has
hundreds or thousands of nodes per subnet, then it must send solicited RAs
unicast.
do we agree that a host that wakes up and has expired its last default
> router should restart router discovery?
>
That's not necessary. For things to work well a host needs to be able to
maintain connectivity even when asleep. So it needs to be able to receive
unicast packets, and it needs to process RAs (e.g., so it can know that it
has lost connectivity when it receives an RA with a default lifetime of 0).
If it is processing RAs, then its RA will not expire.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20150612/696b6432/attachment.htm>
More information about the ipv6-ops
mailing list