push apps failing in Android until you disable IPv6

Ted Mittelstaedt tedm at ipinc.net
Mon May 9 12:30:46 CEST 2016


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 at ipinc.net
>> <mailto:tedm at 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?


More information about the ipv6-ops mailing list