Mailing List Archive

Samsung phones block WiFi IPv6 when sleeping, delayed notifications
Hi,

We have noticed that Samsung Android phones and tablets on dual-stack
IPv4/IPv6 WiFi experience delayed Google notifications when the screen is
off.
This issue is blocking the enabling of IPv6 across our large campus WiFi
network.

Has anyone else experienced this behaviour and escalated this to Samsung,
or found a fix?

Our Samsung liaison person today said
===

---

IPv6 packets are getting filtered due to the current consumption issue
while device is in sleep mode.



*IPv6 Concept of Samsung models:*



When device enters the sleep mode, current implementation is that all the
IPv6 packets from AP are getting blocked. All IPv4 and IPv6 packets are
received while the LCD is on, however LCD off will be in blocked mode.

This is because some of the current AP in markets introduces unnecessary
IPv6 Multicast packets, which in turn wake up the devices which are in
sleep mode, causing the issue of increase in the current consumption.

Therefore a feature is applied on WiFi driver to filter off all IPv6 packets
while in sleep mode.

---



I have requested , How to activate that filter on for all IPv6 packets even
when device at sleep mode. So far, it seems like it’s a permanent
implementation and filter is not customizable for configuration.
===


This problem has been raised before. See
http://commandline.ninja/2014/01/02/samsung-galaxy-s4-ipv6-borked/

http://developer.samsung.com/forum/board/thread/view.do?boardName=General&messageId=239890
---
Hi, this is a serious bug in the WIFI driver of several Samsung Android
phones, which prevents IPv6 enabled WLAN networks to work correctly. The
phone is almost unuseable (while in standby mode) if it is part of a IPv6
enabled wireless, because the lower level link protocol misses to update
routing information and neighbourhood discovery.
...

*This is really a serious IPv6 problem on the broadcom-wifi samsung phones
that should be solved by a coming firmware update for the wifi radio
firmware or kernel driver. In the current state, Samsung phones with that
problem cannot be used in IPv6 enabled wifi networks - and you have no
chance to disable IPv6 on the phone!!!*
---
developers.samsung , Jul 31, 2013 08:46
Hello,

Blocking packets of IPv6 when screen is off is intended because battery
runs down rapidly due to increasing standby power.

End-users can connect to networks continually by IPv4.

Best Regards,
Samsung Developers
---

See also
https://code.google.com/p/android/issues/detail?id=32662

Thanks,
John
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
> On 10 Jun 2015, at 06:33, John Mann <john.mann@monash.edu> wrote:
>
> Hi,
>
> We have noticed that Samsung Android phones and tablets on dual-stack IPv4/IPv6 WiFi experience delayed Google notifications when the screen is off.
> This issue is blocking the enabling of IPv6 across our large campus WiFi network.
>
> Has anyone else experienced this behaviour and escalated this to Samsung, or found a fix?


I see that. I don’t think the problem is confined to Samsung or that it can be completed solved in isolation from fixing wireless AP router behaviour.
At the edge of the WiFi network I also see the IPv6 connectivity dropping while IPv4 stays up. I’ve a ZyXEL home router that sends periodic RAs every 15 seconds
and a Huawei home router that sends them every 1800 seconds.

It isn’t production ready yet.

Ross
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
John,

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.

FWIW, if you need an existence proof that it's possible to make this work,
recent Nexus device should not have either problem. Feel free to ask
Samsung to get in touch with me if they want to know how it works on Nexus.

A network that is configured to send RAs every 15 seconds will have a
devastating effect on battery life, and such networks are part of the
reason that manufacturers drop all multicast packets during sleep. Please
don't do that. Nexus devices rate-limit RAs in firmware in order to survive
on such aggressive networks, but that's not perfect.

Cheers,
Lorenzo

On Wed, Jun 10, 2015 at 2:33 PM, John Mann <john.mann@monash.edu> wrote:

> Hi,
>
> We have noticed that Samsung Android phones and tablets on dual-stack
> IPv4/IPv6 WiFi experience delayed Google notifications when the screen is
> off.
> This issue is blocking the enabling of IPv6 across our large campus WiFi
> network.
>
> Has anyone else experienced this behaviour and escalated this to Samsung,
> or found a fix?
>
> Our Samsung liaison person today said
> ===
>
> ---
>
> IPv6 packets are getting filtered due to the current consumption issue
> while device is in sleep mode.
>
>
>
> *IPv6 Concept of Samsung models:*
>
>
>
> When device enters the sleep mode, current implementation is that all the
> IPv6 packets from AP are getting blocked. All IPv4 and IPv6 packets are
> received while the LCD is on, however LCD off will be in blocked mode.
>
> This is because some of the current AP in markets introduces unnecessary
> IPv6 Multicast packets, which in turn wake up the devices which are in
> sleep mode, causing the issue of increase in the current consumption.
>
> Therefore a feature is applied on WiFi driver to filter off all IPv6 packets
> while in sleep mode.
>
> ---
>
>
>
> I have requested , How to activate that filter on for all IPv6 packets
> even when device at sleep mode. So far, it seems like it’s a permanent
> implementation and filter is not customizable for configuration.
> ===
>
>
> This problem has been raised before. See
> http://commandline.ninja/2014/01/02/samsung-galaxy-s4-ipv6-borked/
>
>
> http://developer.samsung.com/forum/board/thread/view.do?boardName=General&messageId=239890
> ---
> Hi, this is a serious bug in the WIFI driver of several Samsung Android
> phones, which prevents IPv6 enabled WLAN networks to work correctly. The
> phone is almost unuseable (while in standby mode) if it is part of a IPv6
> enabled wireless, because the lower level link protocol misses to update
> routing information and neighbourhood discovery.
> ...
>
> *This is really a serious IPv6 problem on the broadcom-wifi samsung phones
> that should be solved by a coming firmware update for the wifi radio
> firmware or kernel driver. In the current state, Samsung phones with that
> problem cannot be used in IPv6 enabled wifi networks - and you have no
> chance to disable IPv6 on the phone!!!*
> ---
> developers.samsung , Jul 31, 2013 08:46
> Hello,
>
> Blocking packets of IPv6 when screen is off is intended because battery
> runs down rapidly due to increasing standby power.
>
> End-users can connect to networks continually by IPv4.
>
> Best Regards,
> Samsung Developers
> ---
>
> See also
> https://code.google.com/p/android/issues/detail?id=32662
>
> Thanks,
> John
>
>
SV: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
> I see that. I don’t think the problem is confined to Samsung or that it can be completed solved in isolation from fixing wireless AP router behaviour.
> At the edge of the WiFi network I also see the IPv6 connectivity dropping while IPv4 stays up. I’ve a ZyXEL home router that sends periodic RAs every 15 seconds
> and a Huawei home router that sends them every 1800 seconds.

Any opinions on what a sane default value for what the RA interval should be? I have not conserned myself with that interval before, but I see that the residential devices we ship are on a very low interval.


--
Erik Taraldsen
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
> On 10 Jun 2015, at 10:20, <erik.taraldsen@telenor.com> <erik.taraldsen@telenor.com> wrote:
>
>> I see that. I don’t think the problem is confined to Samsung or that it can be completed solved in isolation from fixing wireless AP router behaviour.
>> At the edge of the WiFi network I also see the IPv6 connectivity dropping while IPv4 stays up. I’ve a ZyXEL home router that sends periodic RAs every 15 seconds
>> and a Huawei home router that sends them every 1800 seconds.
>
> Any opinions on what a sane default value for what the RA interval should be? I have not conserned myself with that interval before, but I see that the residential devices we ship are on a very low interval.

I believe our Cisco equipment defaults to 10 minutes (600 seconds). There will also be RAs in response to RS messages.

I’ll try to grab some stats on observed RAs from our campus eduroam network, where we have IPv6 deployed to a few thousand users with BYODs every day. I would guess such stats have been reported elsewhere already, but a few more observations might be useful/interesting.

Tim
SV: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
> I believe our Cisco equipment defaults to 10 minutes (600 seconds). There will also be RAs in response
> to RS messages.

>From the googeling I've done it seems that the defaults span from 180 to 600 seconds. Have not
yet found any reccomandation. Either as a sane dafult value or a calculation from the life time.


--
Erik Taraldsen
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
On 10 Jun 2015, at 10:33, <erik.taraldsen@telenor.com> <erik.taraldsen@telenor.com> wrote:
>
>
>> I believe our Cisco equipment defaults to 10 minutes (600 seconds). There will also be RAs in response
>> to RS messages.
>
> From the googeling I've done it seems that the defaults span from 180 to 600 seconds. Have not
> yet found any reccomandation. Either as a sane dafult value or a calculation from the life time.

And there’s the RAs in response to RS messages, which is why some stats from a live network might be interesting to see. Though we did run for a while with unicast RAs to work around some bug we had with our WLC.

Tim
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
> On 10 Jun 2015, at 10:20, <erik.taraldsen@telenor.com> <erik.taraldsen@telenor.com> wrote:
>
>> I see that. I don’t think the problem is confined to Samsung or that it can be completed solved in isolation from fixing wireless AP router behaviour.
>> At the edge of the WiFi network I also see the IPv6 connectivity dropping while IPv4 stays up. I’ve a ZyXEL home router that sends periodic RAs every 15 seconds
>> and a Huawei home router that sends them every 1800 seconds.
>
> Any opinions on what a sane default value for what the RA interval should be? I have not conserned myself with that interval before, but I see that the residential devices we ship are on a very low interval.
>
>
> --
> Erik Taraldsen

I think tweaking the periodic RA interval time is an inadequate hack made in an attempt to keep IPv6 connectivity up.
It seems to me the correct approach is to have an RFC or otherwise clear guidelines for developers documenting how to optimise this for connectivity parity with IPv4 and device battery life on both the wireless AP router and wireless client.

Ross
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
On 10/06/15 18:23, Lorenzo Colitti wrote:
> are *all* IPv6 packets blocked, or just multicast packets? I know
> that a number of devices will drop multicast IPv6 packets.

On that note, some wireless access points have the ability to convert multicast packets into unicast packets. Both the Cisco and HP systems I have access to support this.

Believe it or not, it’s actually billed as an optimisation, as unicast packets generally use a faster modulation than multicast. Makes sense, because if you send only one copy of a packet wirelessly, all devices (even the ones with the crappiest signals) need to be able to receive it reasonably reliably.

If that option is available to you, and if this is specific to multicast, this may be an interesting hack.
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
* Lorenzo Colitti

> 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.

So unless you're a polyphasic sleeper, the handset will loose
connectivity overnight no matter what...

> A network that is configured to send RAs every 15 seconds will have a
> devastating effect on battery life, and such networks are part of the
> reason that manufacturers drop all multicast packets during sleep.
> Please don't do that. Nexus devices rate-limit RAs in firmware in
> order to survive on such aggressive networks, but that's not perfect.

Frequent unsolicited RAs was how I worked around the above problem.
While my phone would loose connectivity while on my nightstand, at
least with frequent RAs the IPv6 connectivity would recover quickly
once I started using my phone again in the morning. With infrequent
RAs, it would stay broken for a very long time.

But this was a few years ago, so maybe the situation has improved since
then? I imagine the handset could get away with not listening to RAs
while in sleep mode if it did send an RS some time before any of the
information learned from RAs was about to expire, for example.

Tore
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
On Wed, Jun 10, 2015 at 9:45 PM, Tore Anderson <tore@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. :-)


> But this was a few years ago, so maybe the situation has improved since
> then? I imagine the handset could get away with not listening to RAs
> while in sleep mode if it did send an RS some time before any of the
> information learned from RAs was about to expire, for example.
>

It depends on the wifi firmware. On Nexus devices, RAs are allowed through
by the firmware, but rate-limited.

(The rate-limiting is an unfortunate necessity when you have tens of
thousands of nodes on one network and your routers don't support replying
to solicited RAs with unicast packets and end up sending a multicast RAs at
the maximum allowed rate of 1 every 3 seconds.)
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
> On 10 Jun 2015, at 13:42, Jeremy Visser <jeremy@sunriseroad.net> wrote:
>
> On 10/06/15 18:23, Lorenzo Colitti wrote:
>> are *all* IPv6 packets blocked, or just multicast packets? I know
>> that a number of devices will drop multicast IPv6 packets.
>
> On that note, some wireless access points have the ability to convert multicast packets into unicast packets. Both the Cisco and HP systems I have access to support this.
>
> Believe it or not, it’s actually billed as an optimisation, as unicast packets generally use a faster modulation than multicast. Makes sense, because if you send only one copy of a packet wirelessly, all devices (even the ones with the crappiest signals) need to be able to receive it reasonably reliably.
>
> If that option is available to you, and if this is specific to multicast, this may be an interesting hack.

That reminds me, we had an interesting ‘feature’ here where we were seeing triple copies of RAs and also Bonjour messages. The discussion about that led to this info:

http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-0/configuration-guide/b_cg80/b_cg80_chapter_0100110.html <http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-0/configuration-guide/b_cg80/b_cg80_chapter_0100110.html>

which I assume is aimed at those doing multicast video streaming of IP TV or similar (as we do here). That may have some impact on multicast for IPv6.

Tim
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
Lorenzo

On 10 June 2015 at 18:23, Lorenzo Colitti <lorenzo@google.com> wrote:

> John,
>
> 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.
>

Probably *all* IPv6 packets. The phone drops IPv6 ICMP pings, and IPv6
TCP/IP packets (at least)

How I tested:
- Install "Network Info II", "JuicsSSH" and "Netstat Plus" apps.
- Connect the phone and a test PC/server to a dual-stack IPv4/IPv6 network
- use "Network Info II" to find out the phone's global unique IPv6 "wlan0"
WiFi addresses (they begin 2xxx: )
and wlan0 IPv4 address (nnn.nnn.nnn.nnn)

Test 1: ping
- From a PC command prompt do a continuous ping to a phone IPv6 address,
and from another command prompt do a continuous ping to the phone's IPv4
address
- Turn phone screen off, IPv6 pings stop, turn phone screen on, IPv6 pings
re-start, ...

Test 2: TCP/IP
- Run JuicsSSH on phone
- ssh to IPv6 host(name)
- on the IPv6 host start a tcpdump or wireshark looking for the phone's
privacy address (doesn't have ..ff:fe..in it)
- run a command like "vmstat 5 60" to generate a low rate of TCP/IP traffic
over IPv6.
- turn phone screen off
- packet capture shows host re-sends the next line of output multiple times
...
- turn phone screen on
- packet capture shows output catching up

I tried using Netstat Plus to try and work out what connections the phone
had open,
and what they were used for, but it wasn't obvious.
- Google Play services connecting to a IPv4 server on port 5228, and IPv6
server on port 443
- Samsung Push Service connecting to a IPv4 server on port 5223


FWIW, if you need an existence proof that it's possible to make this work,
> recent Nexus device should not have either problem. Feel free to ask
> Samsung to get in touch with me if they want to know how it works on Nexus.
>
> A network that is configured to send RAs every 15 seconds will have a
> devastating effect on battery life, and such networks are part of the
> reason that manufacturers drop all multicast packets during sleep. Please
> don't do that. Nexus devices rate-limit RAs in firmware in order to survive
> on such aggressive networks, but that's not perfect.
>
> Cheers,
> Lorenzo
>

Thanks,
John

On Wed, Jun 10, 2015 at 2:33 PM, John Mann <john.mann@monash.edu> wrote:
>
>> Hi,
>>
>> We have noticed that Samsung Android phones and tablets on dual-stack
>> IPv4/IPv6 WiFi experience delayed Google notifications when the screen is
>> off.
>> This issue is blocking the enabling of IPv6 across our large campus WiFi
>> network.
>>
>> Has anyone else experienced this behaviour and escalated this to Samsung,
>> or found a fix?
>>
>> Our Samsung liaison person today said
>> ===
>>
>> ---
>>
>> IPv6 packets are getting filtered due to the current consumption issue
>> while device is in sleep mode.
>>
>>
>>
>> *IPv6 Concept of Samsung models:*
>>
>>
>>
>> When device enters the sleep mode, current implementation is that all the
>> IPv6 packets from AP are getting blocked. All IPv4 and IPv6 packets are
>> received while the LCD is on, however LCD off will be in blocked mode.
>>
>> This is because some of the current AP in markets introduces unnecessary
>> IPv6 Multicast packets, which in turn wake up the devices which are in
>> sleep mode, causing the issue of increase in the current consumption.
>>
>> Therefore a feature is applied on WiFi driver to filter off all IPv6 packets
>> while in sleep mode.
>>
>> ---
>>
>>
>>
>> I have requested , How to activate that filter on for all IPv6 packets
>> even when device at sleep mode. So far, it seems like it’s a permanent
>> implementation and filter is not customizable for configuration.
>> ===
>>
>>
>> This problem has been raised before. See
>> http://commandline.ninja/2014/01/02/samsung-galaxy-s4-ipv6-borked/
>>
>>
>> http://developer.samsung.com/forum/board/thread/view.do?boardName=General&messageId=239890
>> ---
>> Hi, this is a serious bug in the WIFI driver of several Samsung Android
>> phones, which prevents IPv6 enabled WLAN networks to work correctly. The
>> phone is almost unuseable (while in standby mode) if it is part of a IPv6
>> enabled wireless, because the lower level link protocol misses to update
>> routing information and neighbourhood discovery.
>> ...
>>
>> *This is really a serious IPv6 problem on the broadcom-wifi samsung
>> phones that should be solved by a coming firmware update for the wifi radio
>> firmware or kernel driver. In the current state, Samsung phones with that
>> problem cannot be used in IPv6 enabled wifi networks - and you have no
>> chance to disable IPv6 on the phone!!!*
>> ---
>> developers.samsung , Jul 31, 2013 08:46
>> Hello,
>>
>> Blocking packets of IPv6 when screen is off is intended because battery
>> runs down rapidly due to increasing standby power.
>>
>> End-users can connect to networks continually by IPv4.
>>
>> Best Regards,
>> Samsung Developers
>> ---
>>
>> See also
>> https://code.google.com/p/android/issues/detail?id=32662
>>
>> Thanks,
>> John
>>
>>
>
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
* Lorenzo Colitti <lorenzo@google.com>

> On Wed, Jun 10, 2015 at 9:45 PM, Tore Anderson <tore@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
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
Hi Tore and list,

Tore Anderson <tore@fud.no> writes:

> 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?

ten years ago I've fooled around with various Unixen (FreeBSD, Debian,
Solaris) with this. I don't remember off the head if this was using the
router lifetime field from the RAs or NUD or both, but it did work quite
reasonably. IIRC I managed to get the failover time down to around 5s,
which is still a lot for VoIP, but pretty reasonable for a lot of other
purposes---like TCP standard retransmit intervals, for example:-)


Cheers,

Benedikt

--
Benedikt Stockebrand, Stepladder IT Training+Consulting
Dipl.-Inform. http://www.stepladder-it.com/

Business Grade IPv6 --- Consulting, Training, Projects

BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
> On 12 Jun 2015, at 5:31 , Lorenzo Colitti <lorenzo@google.com> wrote:
>
> On Thu, Jun 11, 2015 at 6:56 PM, Benedikt Stockebrand <bs@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.

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…

RFC4861: "The host re-attaches to a link after being detached for some time.”

I don’t see the purpose of a host re-soliciting unless the last default router is about to expire, NUD fails, strong indication that it has moved…

do we agree that a host that wakes up and has expired its last default router should restart router discovery?
(if I wrote the code on the host, I’d continue to use the expired router until I got a new one).

cheers,
Ole
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
On Fri, Jun 12, 2015 at 4:54 PM, Ole Troan <otroan@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.
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
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@google.com> wrote:
>
> On Fri, Jun 12, 2015 at 4:54 PM, Ole Troan <otroan@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.
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
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@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@google.com> wrote:
> >
> > On Fri, Jun 12, 2015 at 4:54 PM, Ole Troan <otroan@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.
>
>
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
On 6/12/15 1:11 AM, Lorenzo Colitti wrote:
>> Ole said:
>> do we agree that a host that wakes up and has expired its last
>> default router should restart router discovery?

In my mind this makes a lot of sense.

> 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,

Agreed

> and it needs to process RAs

The problem is that due to the design of the protocol "processing RAs"
(Note, you did not specify unicast or multicast) is a known battery
drainer. So it's awesome to say that wireless devices operating on a
battery should simply stick to the protocol that was designed 15+ years
ago when it was almost universally true that every networked device was
connected to power and a LAN cable. But the world has moved on.

> (e.g., so it can
> know that it has lost connectivity when it receives an RA with a default
> lifetime of 0).

The device should know if it loses connectivity if it actually, you
know, loses connectivity. If the router hasn't expired yet it should be
able to use it. The scenario you describe should be incredibly rare.

Doug


--
I am conducting an experiment in the efficacy of PGP/MIME signatures.
This message should be signed. If it is not, or the signature does not
validate, please let me know how you received this message (direct, or
to a list) and the mail software you use. Thanks!
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
On Sun, Jun 14, 2015 at 6:06 AM, Doug Barton <dougb@dougbarton.email> wrote:

> The problem is that due to the design of the protocol "processing RAs"
> (Note, you did not specify unicast or multicast) is a known battery drainer.


On a phone, the cost of receiving one packet every 10 minutes is
completely. Receiving multicast is cheaper than receiving unicast.


> So it's awesome to say that wireless devices operating on a battery should
> simply stick to the protocol that was designed 15+ years ago when it was
> almost universally true that every networked device was connected to power
> and a LAN cable. But the world has moved on.


What do you suggest? Use another protocol instead? Perhaps DHCPv6, whose
semantics are unchanged since DHCPv4 came out in 1993 and which still has
no deployed mechanism to update hosts with new information?

The device should know if it loses connectivity if it actually, you know,
> loses connectivity. If the router hasn't expired yet it should be able to
> use it. The scenario you describe should be incredibly rare.


In an enterprise that has invested in VRRP and BGP multihoming, perhaps. In
a home network, no.
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications [ In reply to ]
On Sun, Jun 14, 2015 at 12:44 PM, Lorenzo Colitti <lorenzo@google.com>
wrote:
>
> On a phone, the cost of receiving one packet every 10 minutes is
> completely.
>

... completely negligible.