<div dir="ltr">Ole,<div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Lorenzo</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 12, 2015 at 5:28 PM, Ole Troan <span dir="ltr"><<a href="mailto:otroan@employees.org" target="_blank">otroan@employees.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Lorenzo,<br>
<br>
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.<br>
<br>
this particular case though sounds like a software bug, rather than an IETF RFC bug.<br>
<br>
cheers,<br>
Ole<br>
<div class="HOEnZb"><div class="h5"><br>
> On 12 Jun 2015, at 10:11 , Lorenzo Colitti <<a href="mailto:lorenzo@google.com">lorenzo@google.com</a>> wrote:<br>
><br>
> On Fri, Jun 12, 2015 at 4:54 PM, Ole Troan <<a href="mailto:otroan@employees.org">otroan@employees.org</a>> wrote:<br>
> > 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.<br>
><br>
> 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…<br>
><br>
> No, that's not what it turns into.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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<br>
><br>
> 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.<br>
><br>
> do we agree that a host that wakes up and has expired its last default router should restart router discovery?<br>
><br>
> 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.<br>
<br>
</div></div></blockquote></div><br></div>