Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[Lorenzo Colitti]

Ole,

Of course. The device can always choose to disconnect. By doing so, it
relinquishes its IP address, disconnects from the link and enters a state
where communications use no power.

Cheers,
Lorenzo

On Fri, Jun 12, 2015 at 5:28 PM, Ole Troan <otroan at employees.org> wrote:

> Lorenzo,
>
> I think we have to ensure that the specifications work for all kinds of
> devices. take a bath scale for example, that’s essentially disconnected
> until someone steps on it. there are going to be levels of deep sleep.
>
> this particular case though sounds like a software bug, rather than an
> IETF RFC bug.
>
> cheers,
> Ole
>
> > On 12 Jun 2015, at 10:11 , Lorenzo Colitti <lorenzo at google.com> wrote:
> >
> > 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: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20150612/c3f76c3d/attachment.html