Mailing List Archive

At least on some Samsung devices there is this known issue where they drop
IPv6 packets when screen-saved.
This is fixed n the Galaxy S7 apparently (I haven't tested myself). I
agree this is a major problem...

http://developer.samsung.com/forum/board/thread/view.do?boardName=General&messageId=239890
http://www.gossamer-threads.com/lists/nsp/ipv6/54641


On Sat, Apr 30, 2016 at 8:03 AM, JORDI PALET MARTINEZ <
jordi.palet@consulintel.es> wrote:

> Hi,
>
> I’m not an Android user, but while doing and IPv6 training, many folks in
> the meeting room told me that they needed to disable IPv6 in the
> router/Android devices, otherwise they aren’t getting the notifications
> from WhatsApp, Facebook, and many other apps.
>
> We have tried disabling energy saving options in Android, and it seems the
> problems is not there. Basically, if the Android device is in stand-by,
> notifications don’t come, until you “open” the Android. Apple and Windows
> devices don’t have this problem.
>
> The scenario seems to happen regardless of the type of CPE (some observed
> this with ADSL, others with GPON).
>
> Just for having a “stable scenario” were to try, we have actually
> replicated this problem with Android 4.4 and 5.1, with an ONT Huawei
> HG8245H, hw v 494.B and firmware v V3R013C00S106.
>
> We have tried using both the ONT as the wireless AP and also disabling the
> WiFi on the ONT and using an external AP. Same problem in both situations.
>
> Don’t look like an issue related to a specific ISP, because the situation
> happens in many different ISPs, and of course none of them provides IPv6 :-(
>
> I’m specially worried because the ISPs are telling the users to disable
> IPv6 everywhere …
>
> Any hints ?
>
> Regards,
> Jordi
>
>
>
>
>
>
>

No, I think is a different issue.

In our case the problem is happening in an IPv4-only network.

For some reason, some bug (I believe) in the IPv6 stack, is avoiding the phone to get the push notifications, until you unlock the screen.

Disabling IPv6 (even if is actually not being used), kills the problem. By killing IPv6 you disable the stack, and thus no link-local addresses ? But clearly seems a problem related to the way the Android is managing the WiFi when IPv6 is enabled, even if only link-local is available.

Reading the post you provided, it looks like IPv4 is still working well ?

Saludos,
Jordi









-----Mensaje original-----
De: <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de> en nombre de Erik Nygren <erik@nygren.org>
Responder a: <erik@nygren.org>
Fecha: sábado, 30 de abril de 2016, 17:33
Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
CC: IPv6 operators forum <ipv6-ops@lists.cluenet.de>
Asunto: Re: push apps failing in Android until you disable IPv6

>At least on some Samsung devices there is this known issue where they drop IPv6 packets when screen-saved.
>
>This is fixed n the Galaxy S7 apparently (I haven't tested myself). I agree this is a major problem...
>
>http://developer.samsung.com/forum/board/thread/view.do?boardName=General&messageId=239890
>http://www.gossamer-threads.com/lists/nsp/ipv6/54641
>
>
>
>On Sat, Apr 30, 2016 at 8:03 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
>
>Hi,
>
>I’m not an Android user, but while doing and IPv6 training, many folks in the meeting room told me that they needed to disable IPv6 in the router/Android devices, otherwise they aren’t getting the notifications from WhatsApp, Facebook, and many other apps.
>
>We have tried disabling energy saving options in Android, and it seems the problems is not there. Basically, if the Android device is in stand-by, notifications don’t come, until you “open” the Android. Apple and Windows devices don’t have this problem.
>
>The scenario seems to happen regardless of the type of CPE (some observed this with ADSL, others with GPON).
>
>Just for having a “stable scenario” were to try, we have actually replicated this problem with Android 4.4 and 5.1, with an ONT Huawei HG8245H, hw v 494.B and firmware v V3R013C00S106.
>
>We have tried using both the ONT as the wireless AP and also disabling the WiFi on the ONT and using an external AP. Same problem in both situations.
>
>Don’t look like an issue related to a specific ISP, because the situation happens in many different ISPs, and of course none of them provides IPv6 :-(
>
>I’m specially worried because the ISPs are telling the users to disable IPv6 everywhere …
>
>Any hints ?
>
>Regards,
>Jordi
>
>
>
>
>
>
>
>
>
>
>

A bug report, especially from a Marshmallow (or even N Developer
Preview) device could be helpful.

What does rdisc6 show on these networks (before IPv6 is disabled)?

[.yep, this is an off-topic comment, but partially it isn't as it does
affect deployability of IPv6 on a device that was build even as shortly
as a year ago...]

On 2016-05-01 03:20, Erik Kline wrote:
> A bug report, especially from a Marshmallow (or even N Developer
> Preview) device could be helpful.

Now if only all Android devices in the field could be actually upgraded
to the newest editions ;)

Indeed, not much Google can do about unless they start requiring that
(guaranteed updates in under a month for a device that has a max age of
say 5 years) from the vendors that use Android... that would be an
amazing step for Internet stability and more importantly security...

Don't think that will ever happen though as there is no money in that,
selling a new device is a great step though...

Greets,
Jeroen

Sorry for the late reply but there is a bug with Android and IPv6 where
if the Android device is booted and for whatever reason SLAAC is not
running on the wifi network the Android device is using, then Android
will not then properly get IPv6 on other wifi networks that ARE enabled.

Typical scenario is user boots their device at home, connects to the
home wifi which does not have IPv6 enabled, or has it enabled but
it's broken, does their thing, then takes the device to a wifi network
with IPv6 enabled, and associates it.

The Android device will pick up the fe80 link-local address just fine
but it won't then pick up the "actual" IPv6 address.

If the IPv6 router is handing it's OWN address out as an IPv6 DNS server
via RDNSS, (which might also be fe80 since they are on the
same subnet) then you have a situation where the Droid device
think's it's on a working IPv6 wifi network (because IPv6 name
resolution is then working) but it cannot reach IPv6 addresses on the
Internet via wifi.

Assuming spacebook and friends are ipv6 enabled, that's why the
notifications are failing, the notifier apps try making an IPv6
connection to spacebook, fail, and give up - rather than keeping
at it and switching down to IPv4.

If the Android device boots on a wifi network with SLAAC properly
running, then there is no problem if it travels from IPv6-enabled
wifi network to IPv6 wifi network.

I ran into this when writing an Android app that mucked around
in the arp table. Also note you won't see the problem unless you
run a terminal app on Android and use ifconfig at the command
line - because the "about phone" under the Settings won't show
any ipv6 if all that there is, is fe80 assigned.

Set your test bed up again to replicate the problem and actually
look at the command line with ifconfig to see what is really
going on when it is failing.

Ted

On 4/30/2016 5:03 AM, JORDI PALET MARTINEZ wrote:
> Hi,
>
> I’m not an Android user, but while doing and IPv6 training, many folks in the meeting room told me that they needed to disable IPv6 in the router/Android devices, otherwise they aren’t getting the notifications from WhatsApp, Facebook, and many other apps.
>
> We have tried disabling energy saving options in Android, and it seems the problems is not there. Basically, if the Android device is in stand-by, notifications don’t come, until you “open” the Android. Apple and Windows devices don’t have this problem.
>
> The scenario seems to happen regardless of the type of CPE (some observed this with ADSL, others with GPON).
>
> Just for having a “stable scenario” were to try, we have actually replicated this problem with Android 4.4 and 5.1, with an ONT Huawei HG8245H, hw v 494.B and firmware v V3R013C00S106.
>
> We have tried using both the ONT as the wireless AP and also disabling the WiFi on the ONT and using an external AP. Same problem in both situations.
>
> Don’t look like an issue related to a specific ISP, because the situation happens in many different ISPs, and of course none of them provides IPv6 :-(
>
> I’m specially worried because the ISPs are telling the users to disable IPv6 everywhere …
>
> Any hints ?
>
> Regards,
> Jordi
>
>
>
>
>
>

Jordi,

from your report it's not clear what the problem is. You say that the
problem disappears when IPv6 is disabled on the router, but then you say
that it also happens on an IPv4-only network. How can those statements both
be true?

It's not usually possible to disable IPv6 on an Android device unless the
device is rooted, which usually involves installing a non-stock build which
may behave differently.

Also, please clarify what device you're talking about. Stock Android should
not have this problem, but some OEMs are known to drop IPv6 packets when
the screen is off.

Cheers,
Lorenzo

On Sat, Apr 30, 2016 at 9:03 PM, JORDI PALET MARTINEZ <
jordi.palet@consulintel.es> wrote:

> Hi,
>
> I’m not an Android user, but while doing and IPv6 training, many folks in
> the meeting room told me that they needed to disable IPv6 in the
> router/Android devices, otherwise they aren’t getting the notifications
> from WhatsApp, Facebook, and many other apps.
>
> We have tried disabling energy saving options in Android, and it seems the
> problems is not there. Basically, if the Android device is in stand-by,
> notifications don’t come, until you “open” the Android. Apple and Windows
> devices don’t have this problem.
>
> The scenario seems to happen regardless of the type of CPE (some observed
> this with ADSL, others with GPON).
>
> Just for having a “stable scenario” were to try, we have actually
> replicated this problem with Android 4.4 and 5.1, with an ONT Huawei
> HG8245H, hw v 494.B and firmware v V3R013C00S106.
>
> We have tried using both the ONT as the wireless AP and also disabling the
> WiFi on the ONT and using an external AP. Same problem in both situations.
>
> Don’t look like an issue related to a specific ISP, because the situation
> happens in many different ISPs, and of course none of them provides IPv6 :-(
>
> I’m specially worried because the ISPs are telling the users to disable
> IPv6 everywhere …
>
> Any hints ?
>
> Regards,
> Jordi
>
>
>
>
>
>
>

On Mon, May 9, 2016 at 5:37 PM, Ted Mittelstaedt <tedm@ipinc.net> wrote:

> Sorry for the late reply but there is a bug with Android and IPv6 where if
> the Android device is booted and for whatever reason SLAAC is not
> running on the wifi network the Android device is using, then Android will
> not then properly get IPv6 on other wifi networks that ARE enabled.
>

That should not be the case. Is there an existing bug for this? If not, can
you open one?

Hi Lorenzo,

I don’t have an Android, so I can’t try myself, unfortunately, so I’m just replicating what several folks told me in a training (people from different ISPs, not just one).

I’ve asked already a few days ago for more info, but still didn’t got it. I also asked to open a bug report as Erik suggested as well as the rdisc6 from the same LAN.

Let me try to write it down again the issue:

1) ISP NOT providing IPv6, but CPE supports IPv6, which can be seen in the router configs and the routers has link local, and you can ping with link local to the router in the LAN. Clearly, router has not GUA.

2) iPhone working fine.

3) Android fails to receive IPv4 push from whatsapp, Facebook, others, when screen is off.

4) Disabling IPv6 in the router the problem disappears.

5) Complains to ISPs are responded with “disable IPv6 in the router”, is not useful at all :-(

I can provide links to web pages from at least one “big” ISP, where they talk about this, but is in Spanish …

I will ping right now again for more info and come back asap.

Thanks !

Regards,
Jordi









-----Mensaje original-----
De: <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de> en nombre de Lorenzo Colitti <lorenzo@google.com>
Responder a: <lorenzo@google.com>
Fecha: lunes, 9 de mayo de 2016, 10:41
Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>
Asunto: Re: push apps failing in Android until you disable IPv6

>Jordi,
>from your report it's not clear what the problem is. You say that the problem disappears when IPv6 is disabled on the router, but then you say that it also happens on an IPv4-only network. How can those statements both be true?
>
>It's not usually possible to disable IPv6 on an Android device unless the device is rooted, which usually involves installing a non-stock build which may behave differently.
>
>Also, please clarify what device you're talking about. Stock Android should not have this problem, but some OEMs are known to drop IPv6 packets when the screen is off.
>
>Cheers,
>Lorenzo
>
>On Sat, Apr 30, 2016 at 9:03 PM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
>
>Hi,
>
>I’m not an Android user, but while doing and IPv6 training, many folks in the meeting room told me that they needed to disable IPv6 in the router/Android devices, otherwise they aren’t getting the notifications from WhatsApp, Facebook, and many other apps.
>
>We have tried disabling energy saving options in Android, and it seems the problems is not there. Basically, if the Android device is in stand-by, notifications don’t come, until you “open” the Android. Apple and Windows devices don’t have this problem.
>
>The scenario seems to happen regardless of the type of CPE (some observed this with ADSL, others with GPON).
>
>Just for having a “stable scenario” were to try, we have actually replicated this problem with Android 4.4 and 5.1, with an ONT Huawei HG8245H, hw v 494.B and firmware v V3R013C00S106.
>
>We have tried using both the ONT as the wireless AP and also disabling the WiFi on the ONT and using an external AP. Same problem in both situations.
>
>Don’t look like an issue related to a specific ISP, because the situation happens in many different ISPs, and of course none of them provides IPv6 :-(
>
>I’m specially worried because the ISPs are telling the users to disable IPv6 everywhere …
>
>Any hints ?
>
>Regards,
>Jordi
>
>
>
>
>
>
>
>
>
>
>
>

If this router were to send out an RA advertising itself as a default
router in this configuration that would probably cause the symptoms
you're seeing. That's why I asked for a sample of any RAs seen on
such a network. (Such a configuration would of course be broken,
effectively requiring Happy Eyeballs to function at all.)

On 9 May 2016 at 17:52, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
> Hi Lorenzo,
>
> I don’t have an Android, so I can’t try myself, unfortunately, so I’m just replicating what several folks told me in a training (people from different ISPs, not just one).
>
> I’ve asked already a few days ago for more info, but still didn’t got it. I also asked to open a bug report as Erik suggested as well as the rdisc6 from the same LAN.
>
> Let me try to write it down again the issue:
>
> 1) ISP NOT providing IPv6, but CPE supports IPv6, which can be seen in the router configs and the routers has link local, and you can ping with link local to the router in the LAN. Clearly, router has not GUA.
>
> 2) iPhone working fine.
>
> 3) Android fails to receive IPv4 push from whatsapp, Facebook, others, when screen is off.
>
> 4) Disabling IPv6 in the router the problem disappears.
>
> 5) Complains to ISPs are responded with “disable IPv6 in the router”, is not useful at all :-(
>
> I can provide links to web pages from at least one “big” ISP, where they talk about this, but is in Spanish …
>
> I will ping right now again for more info and come back asap.
>
> Thanks !
>
> Regards,
> Jordi
>
>
>
>
>
>
>
>
>
> -----Mensaje original-----
> De: <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de> en nombre de Lorenzo Colitti <lorenzo@google.com>
> Responder a: <lorenzo@google.com>
> Fecha: lunes, 9 de mayo de 2016, 10:41
> Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
> CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>
> Asunto: Re: push apps failing in Android until you disable IPv6
>
>>Jordi,
>>from your report it's not clear what the problem is. You say that the problem disappears when IPv6 is disabled on the router, but then you say that it also happens on an IPv4-only network. How can those statements both be true?
>>
>>It's not usually possible to disable IPv6 on an Android device unless the device is rooted, which usually involves installing a non-stock build which may behave differently.
>>
>>Also, please clarify what device you're talking about. Stock Android should not have this problem, but some OEMs are known to drop IPv6 packets when the screen is off.
>>
>>Cheers,
>>Lorenzo
>>
>>On Sat, Apr 30, 2016 at 9:03 PM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
>>
>>Hi,
>>
>>I’m not an Android user, but while doing and IPv6 training, many folks in the meeting room told me that they needed to disable IPv6 in the router/Android devices, otherwise they aren’t getting the notifications from WhatsApp, Facebook, and many other apps.
>>
>>We have tried disabling energy saving options in Android, and it seems the problems is not there. Basically, if the Android device is in stand-by, notifications don’t come, until you “open” the Android. Apple and Windows devices don’t have this problem.
>>
>>The scenario seems to happen regardless of the type of CPE (some observed this with ADSL, others with GPON).
>>
>>Just for having a “stable scenario” were to try, we have actually replicated this problem with Android 4.4 and 5.1, with an ONT Huawei HG8245H, hw v 494.B and firmware v V3R013C00S106.
>>
>>We have tried using both the ONT as the wireless AP and also disabling the WiFi on the ONT and using an external AP. Same problem in both situations.
>>
>>Don’t look like an issue related to a specific ISP, because the situation happens in many different ISPs, and of course none of them provides IPv6 :-(
>>
>>I’m specially worried because the ISPs are telling the users to disable IPv6 everywhere …
>>
>>Any hints ?
>>
>>Regards,
>>Jordi
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>

* Erik Kline <ek@google.com>

> If this router were to send out an RA advertising itself as a default
> router in this configuration that would probably cause the symptoms
> you're seeing. That's why I asked for a sample of any RAs seen on
> such a network. (Such a configuration would of course be broken,
> effectively requiring Happy Eyeballs to function at all.)

Assuming the source address selection is implemented in a sane way,
just having a an IPv6 default router doesn't on its own explain the
symptoms described. IPv4 should be preferred due to the Android device's
link-local address not having the same scope as the IPv6 address of the
web site or whatever. See RFC6724 sections 5 and 6, rule 2.

The RA would have to additionally contain a PIO with global scope, as I
understand it. Then you'd certainly get in trouble (disregarding Happy
Eyeballs). Even a ULA PIO could be problematic if Android's source
address selection algorithm isn't updated to RFC6724 defaults. RFC3484
predates ULAs, so it treats them the same as other globally scoped
addresses.

Tore

I haven't looked for an existing bug to be honest. I only noticed it
and put 2 and 2 together quite recently and I haven't tried to replicate it.

I saw it on a rooted Motorola Moto G running 5.1. The situation
was that my ISP (Comcast) had renumbered IPv6 to a new subnet
but had failed to push out the new subnet to the CPE. My operating
network is behind a Cisco 2800 that runs DHCP-PD to obtain an IPv6
subnet from the Comcast CPE. During testing to figure out WTF that
Comcast was up to, I happened to reboot my phone during all this and
noticed that my app was showing the phone with a link-local IPv6 address
but no actual IPv6 address. At that time the Cisco was
advertising IPv6 but it had no usable delegation from the Comcast CPE.
Once I renumbered the Cisco and got my other IPv6 stuff working, instead
of rebooting the phone I tried disassociating it from the IPv6
wifi network and re-associating it, assuming that the phone would
pick up the correct IPv6 now that the router was properly numbered.
It didn't, though, and didn't until I booted it. Because I was much more
focused on what Comcast was doing, I didn't pursue it.

I'll see if I can make it break again and post a followup to this
email in a few minutes if I can.

Ted

On 5/9/2016 1:41 AM, Lorenzo Colitti wrote:
> On Mon, May 9, 2016 at 5:37 PM, Ted Mittelstaedt <tedm@ipinc.net
> <mailto:tedm@ipinc.net>> wrote:
>
> Sorry for the late reply but there is a bug with Android and IPv6
> where if the Android device is booted and for whatever reason SLAAC
> is not
> running on the wifi network the Android device is using, then
> Android will not then properly get IPv6 on other wifi networks that
> ARE enabled.
>
>
> That should not be the case. Is there an existing bug for this? If not,
> can you open one?

All true.

I forgot to say that we've seen (years ago) routers than announced
2001:db8::/something, and if this were doing such a thing that could
lead to this situation.

On 9 May 2016 at 18:17, Tore Anderson <tore@fud.no> wrote:
> * Erik Kline <ek@google.com>
>
>> If this router were to send out an RA advertising itself as a default
>> router in this configuration that would probably cause the symptoms
>> you're seeing. That's why I asked for a sample of any RAs seen on
>> such a network. (Such a configuration would of course be broken,
>> effectively requiring Happy Eyeballs to function at all.)
>
> Assuming the source address selection is implemented in a sane way,
> just having a an IPv6 default router doesn't on its own explain the
> symptoms described. IPv4 should be preferred due to the Android device's
> link-local address not having the same scope as the IPv6 address of the
> web site or whatever. See RFC6724 sections 5 and 6, rule 2.
>
> The RA would have to additionally contain a PIO with global scope, as I
> understand it. Then you'd certainly get in trouble (disregarding Happy
> Eyeballs). Even a ULA PIO could be problematic if Android's source
> address selection algorithm isn't updated to RFC6724 defaults. RFC3484
> predates ULAs, so it treats them the same as other globally scoped
> addresses.
>
> Tore

Well here is what I'm finding.

If I merely enable ipv6 on my private interface on my cisco 2800
then Android will pick up a link-local address only - as it should.

If I then attempt to ping6 a host on the Internet, I just get
a request timeout.

given what Jordi reported, this is consistent behavior - the
situation is - you have a router that (in my case) is a legitimate
default GW via IPv6 but is either advertising a completely bogus IPv6
subnet or not advertising a valid subnet at all to it's "inside"
clients, yet is advertising itself as a default GW for IPv6,
and when those clients then attempt to send out IPv6 traffic via
that router using only the link-local address, they fail.

Windows breaks exactly the same way. So I have to assume my
initial speculation about the notifications is supported by this
test. The notifications are attempting an IPv6 connection
through an IPv6 router that is advertising itself as a gateway
but actually isn't. Instead of failing and then falling back to IPv4,
the notifications are just aborting.

Since link-local addresses should never be used as a source
address for IPv6 traffic to a remote subnet, a workaround would be
for Android to check the stack - and if it only has link-local
addressing, even if it's receiving correct RA packets, to assume
the router doesn't have functioning IPv6 and just shut IPv6 off.

Of course this would break any "IPv6 translation schemes" I think
but that would be a Good Thing.

I don't know though that I'd classify this as a bug, though,
since the correct solution would be for an out-of-the-box ISP router
connection to an ISP that does not supply IPv6, to either not have IPv6
enabled on the router, or to not advertise itself as an IPv6 gateway.

Ted

On 5/9/2016 2:21 AM, Ted Mittelstaedt wrote:
>
> I haven't looked for an existing bug to be honest. I only noticed it and
> put 2 and 2 together quite recently and I haven't tried to replicate it.
>
> I saw it on a rooted Motorola Moto G running 5.1. The situation
> was that my ISP (Comcast) had renumbered IPv6 to a new subnet
> but had failed to push out the new subnet to the CPE. My operating
> network is behind a Cisco 2800 that runs DHCP-PD to obtain an IPv6
> subnet from the Comcast CPE. During testing to figure out WTF that
> Comcast was up to, I happened to reboot my phone during all this and
> noticed that my app was showing the phone with a link-local IPv6 address
> but no actual IPv6 address. At that time the Cisco was
> advertising IPv6 but it had no usable delegation from the Comcast CPE.
> Once I renumbered the Cisco and got my other IPv6 stuff working, instead
> of rebooting the phone I tried disassociating it from the IPv6
> wifi network and re-associating it, assuming that the phone would
> pick up the correct IPv6 now that the router was properly numbered.
> It didn't, though, and didn't until I booted it. Because I was much more
> focused on what Comcast was doing, I didn't pursue it.
>
> I'll see if I can make it break again and post a followup to this
> email in a few minutes if I can.
>
> Ted
>
> On 5/9/2016 1:41 AM, Lorenzo Colitti wrote:
>> On Mon, May 9, 2016 at 5:37 PM, Ted Mittelstaedt <tedm@ipinc.net
>> <mailto:tedm@ipinc.net>> wrote:
>>
>> Sorry for the late reply but there is a bug with Android and IPv6
>> where if the Android device is booted and for whatever reason SLAAC
>> is not
>> running on the wifi network the Android device is using, then
>> Android will not then properly get IPv6 on other wifi networks that
>> ARE enabled.
>>
>>
>> That should not be the case. Is there an existing bug for this? If not,
>> can you open one?

> On 9 May 2016, at 10:17, Tore Anderson <tore@fud.no> wrote:
>
> * Erik Kline <ek@google.com>
>
>> If this router were to send out an RA advertising itself as a default
>> router in this configuration that would probably cause the symptoms
>> you're seeing. That's why I asked for a sample of any RAs seen on
>> such a network. (Such a configuration would of course be broken,
>> effectively requiring Happy Eyeballs to function at all.)
>
> Assuming the source address selection is implemented in a sane way,
> just having a an IPv6 default router doesn't on its own explain the
> symptoms described. IPv4 should be preferred due to the Android device's
> link-local address not having the same scope as the IPv6 address of the
> web site or whatever. See RFC6724 sections 5 and 6, rule 2.
>
> The RA would have to additionally contain a PIO with global scope, as I
> understand it. Then you'd certainly get in trouble (disregarding Happy
> Eyeballs). Even a ULA PIO could be problematic if Android's source
> address selection algorithm isn't updated to RFC6724 defaults. RFC3484
> predates ULAs, so it treats them the same as other globally scoped
> addresses.

This was one of the reasons for the RFC 6724 update, and would fit the symptoms being described were the device using older heuristics, but it sounds like the device has only LL and not ULA, right Ted?

Tim

How do you know that the non-received notifications are IPv4 packets?

On Mon, May 9, 2016 at 4:52 AM, JORDI PALET MARTINEZ <
jordi.palet@consulintel.es> wrote:

>
> 3) Android fails to receive IPv4 push from whatsapp, Facebook, others,
> when screen is off.
>
> 4) Disabling IPv6 in the router the problem disappears.
>
>

Because if the ISP doesn’t offer IPv6 service, it can’t (or should not !) be IPv6, right ?

Saludos,
Jordi









-----Mensaje original-----
De: <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de> en nombre de jm33 <jamesm33@gmail.com>
Responder a: <jamesm33@gmail.com>
Fecha: lunes, 9 de mayo de 2016, 16:01
Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>, <lorenzo@google.com>
Asunto: Re: push apps failing in Android until you disable IPv6

>How do you know that the non-received notifications are IPv4 packets?
>
>On Mon, May 9, 2016 at 4:52 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
>
>
>3) Android fails to receive IPv4 push from whatsapp, Facebook, others, when screen is off.
>
>4) Disabling IPv6 in the router the problem disappears.
>
>
>
>
>
>

> On 9 May 2016, at 15:05, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
>
> Because if the ISP doesn’t offer IPv6 service, it can’t (or should not !) be IPv6, right ?

It’s not unheard of for an ISP to update customer firmware for v6 support in advance of deploying connectivity and addressing, with the result that the CPE offers ULAs internally even though there's no IPv6 provisioning in place, and 3484-style devices then having issues. Would be interesting as an aside to know the status of 3484 vs 6724 on various OSes, as well as those like OSX that appear to do their own thing.

Tim

>
> Saludos,
> Jordi
>
>
>
>
>
>
>
>
>
> -----Mensaje original-----
> De: <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de> en nombre de jm33 <jamesm33@gmail.com>
> Responder a: <jamesm33@gmail.com>
> Fecha: lunes, 9 de mayo de 2016, 16:01
> Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
> CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>, <lorenzo@google.com>
> Asunto: Re: push apps failing in Android until you disable IPv6
>
>> How do you know that the non-received notifications are IPv4 packets?
>>
>> On Mon, May 9, 2016 at 4:52 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
>>
>>
>> 3) Android fails to receive IPv4 push from whatsapp, Facebook, others, when screen is off.
>>
>> 4) Disabling IPv6 in the router the problem disappears.
>>
>>
>>
>>
>>
>>
>
>

Hi Tim,

I’ve asked for this info, but I’m almost sure (they show me a VNC from a remote location of the router config) that the router is only having link-local, ULA was disabled by default in the router (all the low cost CPEs that I’ve seen up to now, with IPv6 support, had ULA disabled by default).

Regards,
Jordi









-----Mensaje original-----
De: <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de> en nombre de Tim Chown <Tim.Chown@jisc.ac.uk>
Responder a: <Tim.Chown@jisc.ac.uk>
Fecha: lunes, 9 de mayo de 2016, 16:14
Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
CC: "ipv6-ops@lists.cluenet.de" <ipv6-ops@lists.cluenet.de>
Asunto: Re: push apps failing in Android until you disable IPv6

>> On 9 May 2016, at 15:05, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
>>
>> Because if the ISP doesn’t offer IPv6 service, it can’t (or should not !) be IPv6, right ?
>
>It’s not unheard of for an ISP to update customer firmware for v6 support in advance of deploying connectivity and addressing, with the result that the CPE offers ULAs internally even though there's no IPv6 provisioning in place, and 3484-style devices then having issues. Would be interesting as an aside to know the status of 3484 vs 6724 on various OSes, as well as those like OSX that appear to do their own thing.
>
>Tim
>
>>
>> Saludos,
>> Jordi
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -----Mensaje original-----
>> De: <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de> en nombre de jm33 <jamesm33@gmail.com>
>> Responder a: <jamesm33@gmail.com>
>> Fecha: lunes, 9 de mayo de 2016, 16:01
>> Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
>> CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>, <lorenzo@google.com>
>> Asunto: Re: push apps failing in Android until you disable IPv6
>>
>>> How do you know that the non-received notifications are IPv4 packets?
>>>
>>> On Mon, May 9, 2016 at 4:52 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
>>>
>>>
>>> 3) Android fails to receive IPv4 push from whatsapp, Facebook, others, when screen is off.
>>>
>>> 4) Disabling IPv6 in the router the problem disappears.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>

On Mon, May 9, 2016 at 6:17 PM, Tore Anderson <tore@fud.no> wrote:

> Even a ULA PIO could be problematic if Android's source
> address selection algorithm isn't updated to RFC6724 defaults. RFC3484
> predates ULAs, so it treats them the same as other globally scoped
> addresses.
>

Android's source address selection was updated to RFC 6724 in early 2013 [
commit
<https://android.googlesource.com/platform/bionic/+/378b0e1ea298ab4b8653e4b95e24d0cc0029414c>].
I think that went into 4.3.

On 2016-05-09 19:28, Lorenzo Colitti wrote:
> On Mon, May 9, 2016 at 6:17 PM, Tore Anderson <tore@fud.no
> <mailto:tore@fud.no>> wrote:
>
> Even a ULA PIO could be problematic if Android's source
> address selection algorithm isn't updated to RFC6724 defaults. RFC3484
> predates ULAs, so it treats them the same as other globally scoped
> addresses.
>
>
> Android's source address selection was updated to RFC 6724 in early 2013
> [commit
> <https://android.googlesource.com/platform/bionic/+/378b0e1ea298ab4b8653e4b95e24d0cc0029414c>].
> I think that went into 4.3.

And how many devices will thus actually receive such an update? 3%?

Oh, not too much off:

http://www.statista.com/statistics/271774/share-of-android-platforms-on-mobile-devices-with-android-os/

4.3 has 2.9% of the market, same amount as people still running 2.3.x...
but fortunately apparently some people have been replacing devices with
4.4, at 32%, not as bad as for actual security issues that are still
available on all those platforms though. And that is all assuming it
really landed in 4.3 and not in a 5.x branch....

Now to hope that one day DHCPv6 gets added.... and then the long long
tail of having all those ancient versions going extinct.

Would be so amazing if Google forced vendors to actually support their
devices for a long time and otherwise not allow those devices to use
Google services, would be a great first step... though more important
for security than for IPv6...

Greets,
Jeroen

Just got a “screen” capture from one of those situations (rdisc6).

Hopefully is useful ! They made it from a virtual machine in the same network as the Androids have the problema, having the VMware interfaces in bridge mode.

Saludos,
Jordi









-----Mensaje original-----
De: <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de> en nombre de Erik Kline <ek@google.com>
Responder a: <ek@google.com>
Fecha: lunes, 9 de mayo de 2016, 10:59
Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>, Lorenzo Colitti <lorenzo@google.com>
Asunto: Re: push apps failing in Android until you disable IPv6

>If this router were to send out an RA advertising itself as a default
>router in this configuration that would probably cause the symptoms
>you're seeing. That's why I asked for a sample of any RAs seen on
>such a network. (Such a configuration would of course be broken,
>effectively requiring Happy Eyeballs to function at all.)
>
>On 9 May 2016 at 17:52, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
>> Hi Lorenzo,
>>
>> I don’t have an Android, so I can’t try myself, unfortunately, so I’m just replicating what several folks told me in a training (people from different ISPs, not just one).
>>
>> I’ve asked already a few days ago for more info, but still didn’t got it. I also asked to open a bug report as Erik suggested as well as the rdisc6 from the same LAN.
>>
>> Let me try to write it down again the issue:
>>
>> 1) ISP NOT providing IPv6, but CPE supports IPv6, which can be seen in the router configs and the routers has link local, and you can ping with link local to the router in the LAN. Clearly, router has not GUA.
>>
>> 2) iPhone working fine.
>>
>> 3) Android fails to receive IPv4 push from whatsapp, Facebook, others, when screen is off.
>>
>> 4) Disabling IPv6 in the router the problem disappears.
>>
>> 5) Complains to ISPs are responded with “disable IPv6 in the router”, is not useful at all :-(
>>
>> I can provide links to web pages from at least one “big” ISP, where they talk about this, but is in Spanish …
>>
>> I will ping right now again for more info and come back asap.
>>
>> Thanks !
>>
>> Regards,
>> Jordi
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -----Mensaje original-----
>> De: <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de> en nombre de Lorenzo Colitti <lorenzo@google.com>
>> Responder a: <lorenzo@google.com>
>> Fecha: lunes, 9 de mayo de 2016, 10:41
>> Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
>> CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>
>> Asunto: Re: push apps failing in Android until you disable IPv6
>>
>>>Jordi,
>>>from your report it's not clear what the problem is. You say that the problem disappears when IPv6 is disabled on the router, but then you say that it also happens on an IPv4-only network. How can those statements both be true?
>>>
>>>It's not usually possible to disable IPv6 on an Android device unless the device is rooted, which usually involves installing a non-stock build which may behave differently.
>>>
>>>Also, please clarify what device you're talking about. Stock Android should not have this problem, but some OEMs are known to drop IPv6 packets when the screen is off.
>>>
>>>Cheers,
>>>Lorenzo
>>>
>>>On Sat, Apr 30, 2016 at 9:03 PM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
>>>
>>>Hi,
>>>
>>>I’m not an Android user, but while doing and IPv6 training, many folks in the meeting room told me that they needed to disable IPv6 in the router/Android devices, otherwise they aren’t getting the notifications from WhatsApp, Facebook, and many other apps.
>>>
>>>We have tried disabling energy saving options in Android, and it seems the problems is not there. Basically, if the Android device is in stand-by, notifications don’t come, until you “open” the Android. Apple and Windows devices don’t have this problem.
>>>
>>>The scenario seems to happen regardless of the type of CPE (some observed this with ADSL, others with GPON).
>>>
>>>Just for having a “stable scenario” were to try, we have actually replicated this problem with Android 4.4 and 5.1, with an ONT Huawei HG8245H, hw v 494.B and firmware v V3R013C00S106.
>>>
>>>We have tried using both the ONT as the wireless AP and also disabling the WiFi on the ONT and using an external AP. Same problem in both situations.
>>>
>>>Don’t look like an issue related to a specific ISP, because the situation happens in many different ISPs, and of course none of them provides IPv6 :-(
>>>
>>>I’m specially worried because the ISPs are telling the users to disable IPv6 everywhere …
>>>
>>>Any hints ?
>>>
>>>Regards,
>>>Jordi
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>

On Mon, 9 May 2016, Jeroen Massar wrote:

> From: Jeroen Massar <jeroen@massar.ch>
>
> On 2016-05-09 19:28, Lorenzo Colitti wrote:
>> On Mon, May 9, 2016 at 6:17 PM, Tore Anderson <tore@fud.no
>> <mailto:tore@fud.no>> wrote:
>>
>> Even a ULA PIO could be problematic if Android's source
>> address selection algorithm isn't updated to RFC6724 defaults. RFC3484
>> predates ULAs, so it treats them the same as other globally scoped
>> addresses.
>>
>>
>> Android's source address selection was updated to RFC 6724 in early 2013
>> [commit
>> <https://android.googlesource.com/platform/bionic/+/378b0e1ea298ab4b8653e4b95e24d0cc0029414c>].
>> I think that went into 4.3.
>
> And how many devices will thus actually receive such an update? 3%?
>
> Oh, not too much off:
>
> http://www.statista.com/statistics/271774/share-of-android-platforms-on-mobile-devices-with-android-os/

3% would only make sense if updates were not also incorporated into later
releases. Those graphs suggest the uptake is significantly higher than
just 3%. On the other hand, the pre-4.3 releases still account for a
not-insignificant share.

Antonio Querubin
e-mail: tony@lavanauts.org
xmpp: antonioquerubin@gmail.com

On Tue, May 10, 2016 at 2:34 AM, Jeroen Massar <jeroen@massar.ch> wrote:

> > I think that went into 4.3.
>
> And how many devices will thus actually receive such an update? 3%?
>
> Oh, not too much off:
>
>
> http://www.statista.com/statistics/271774/share-of-android-platforms-on-mobile-devices-with-android-os/


No, *way* off. If you look at your graph again you'll see the number is
almost 80%.

(Copied back to the list, as the list filtered the original message with the screen capture attachment)

For the info of the list. This is what the rdisc6 provided:

Hop Limit: 64 (0x40)
Stateful address cons.: No
Stateful other cons.: Yes
Router preference: medium
Router lifetime: 1800 (0x00000708) seconds
Reachable time: unspecified (0x00000000)
Retransmit time: unspecified (0x00000000)

MTU: 1472 bytes (valid)
Source link-layer address: 2C:CF:58:E5:7C:C0
From fe80::1

Right, but how this is affecting IPv4 push notifications ?

My understanding is that the servers doing the “push”, as the WAN link has not got IPv6, are doing the push with IPv4.

I could understand that Android may be slower to react to dual-stack traffic because there is a default route announced by the router with no GUA, but getting the push ?

By the way, anyone got rdisc6 working in Mac OS X El Capitan ?

Regards,
Jordi









-----Mensaje original-----
De: Erik Kline <ek@google.com>
Responder a: <ek@google.com>
Fecha: martes, 10 de mayo de 2016, 4:41
Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
CC: Lorenzo Colitti <lorenzo@google.com>
Asunto: Re: push apps failing in Android until you disable IPv6

>Uh...non-zero router lifetime means it's announcing a default route.
>That seems unwise.
>
>On 10 May 2016 at 02:49, JORDI PALET MARTINEZ
><jordi.palet@consulintel.es> wrote:
>> Just got a “screen” capture from one of those situations (rdisc6).
>>
>> Hopefully is useful ! They made it from a virtual machine in the same network as the Androids have the problema, having the VMware interfaces in bridge mode.
>>
>> Saludos,
>> Jordi
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -----Mensaje original-----
>> De: <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de> en nombre de Erik Kline <ek@google.com>
>> Responder a: <ek@google.com>
>> Fecha: lunes, 9 de mayo de 2016, 10:59
>> Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
>> CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>, Lorenzo Colitti <lorenzo@google.com>
>> Asunto: Re: push apps failing in Android until you disable IPv6
>>
>>>If this router were to send out an RA advertising itself as a default
>>>router in this configuration that would probably cause the symptoms
>>>you're seeing. That's why I asked for a sample of any RAs seen on
>>>such a network. (Such a configuration would of course be broken,
>>>effectively requiring Happy Eyeballs to function at all.)
>>>
>>>On 9 May 2016 at 17:52, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
>>>> Hi Lorenzo,
>>>>
>>>> I don’t have an Android, so I can’t try myself, unfortunately, so I’m just replicating what several folks told me in a training (people from different ISPs, not just one).
>>>>
>>>> I’ve asked already a few days ago for more info, but still didn’t got it. I also asked to open a bug report as Erik suggested as well as the rdisc6 from the same LAN.
>>>>
>>>> Let me try to write it down again the issue:
>>>>
>>>> 1) ISP NOT providing IPv6, but CPE supports IPv6, which can be seen in the router configs and the routers has link local, and you can ping with link local to the router in the LAN. Clearly, router has not GUA.
>>>>
>>>> 2) iPhone working fine.
>>>>
>>>> 3) Android fails to receive IPv4 push from whatsapp, Facebook, others, when screen is off.
>>>>
>>>> 4) Disabling IPv6 in the router the problem disappears.
>>>>
>>>> 5) Complains to ISPs are responded with “disable IPv6 in the router”, is not useful at all :-(
>>>>
>>>> I can provide links to web pages from at least one “big” ISP, where they talk about this, but is in Spanish …
>>>>
>>>> I will ping right now again for more info and come back asap.
>>>>
>>>> Thanks !
>>>>
>>>> Regards,
>>>> Jordi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Mensaje original-----
>>>> De: <ipv6-ops-bounces+jordi.palet=consulintel.es@lists.cluenet.de> en nombre de Lorenzo Colitti <lorenzo@google.com>
>>>> Responder a: <lorenzo@google.com>
>>>> Fecha: lunes, 9 de mayo de 2016, 10:41
>>>> Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
>>>> CC: IPv6 Ops list <ipv6-ops@lists.cluenet.de>
>>>> Asunto: Re: push apps failing in Android until you disable IPv6
>>>>
>>>>>Jordi,
>>>>>from your report it's not clear what the problem is. You say that the problem disappears when IPv6 is disabled on the router, but then you say that it also happens on an IPv4-only network. How can those statements both be true?
>>>>>
>>>>>It's not usually possible to disable IPv6 on an Android device unless the device is rooted, which usually involves installing a non-stock build which may behave differently.
>>>>>
>>>>>Also, please clarify what device you're talking about. Stock Android should not have this problem, but some OEMs are known to drop IPv6 packets when the screen is off.
>>>>>
>>>>>Cheers,
>>>>>Lorenzo
>>>>>
>>>>>On Sat, Apr 30, 2016 at 9:03 PM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
>>>>>
>>>>>Hi,
>>>>>
>>>>>I’m not an Android user, but while doing and IPv6 training, many folks in the meeting room told me that they needed to disable IPv6 in the router/Android devices, otherwise they aren’t getting the notifications from WhatsApp, Facebook, and many other apps.
>>>>>
>>>>>We have tried disabling energy saving options in Android, and it seems the problems is not there. Basically, if the Android device is in stand-by, notifications don’t come, until you “open” the Android. Apple and Windows devices don’t have this problem.
>>>>>
>>>>>The scenario seems to happen regardless of the type of CPE (some observed this with ADSL, others with GPON).
>>>>>
>>>>>Just for having a “stable scenario” were to try, we have actually replicated this problem with Android 4.4 and 5.1, with an ONT Huawei HG8245H, hw v 494.B and firmware v V3R013C00S106.
>>>>>
>>>>>We have tried using both the ONT as the wireless AP and also disabling the WiFi on the ONT and using an external AP. Same problem in both situations.
>>>>>
>>>>>Don’t look like an issue related to a specific ISP, because the situation happens in many different ISPs, and of course none of them provides IPv6 :-(
>>>>>
>>>>>I’m specially worried because the ISPs are telling the users to disable IPv6 everywhere …
>>>>>
>>>>>Any hints ?
>>>>>
>>>>>Regards,
>>>>>Jordi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>