After much hand-wringing about the 'optimal' IPv6 address dispensation solution (current state of affairs seems to work out to 'there isn't one'), I finally worked my way back to the default, out-of-box configuration - both RA and DHCPv6 fully enabled courtesy of odhcpd.

That having been said, in my checkered past as a Tomato developer, I had little issue getting my Android (4.4.2) phone to get a SLAAC IPv6 from Tomato routers (and derivatives like AsusWRT Merlin), including DNS, using radvd.

For some reason, I just can't seem to get odhcpd to cooperate.  My dhcp.conf looks as follows (which, as far as I know, is basically OpenWRT default):

...

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv6 'server'
        option ra 'server'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'

...

Doing a tcpdump trace on the wireless MAC of my phone shows a router solicitation, followed by a router advertisement for an IPv6 network for fe80::... - and that's it.

I'm pretty stumped here - I figured in the worst case, it would pick up a SLAAC address and default gateway, but perhaps no DNS servers (since I believe they are only served up via DHCPv6 on OpenWRT)...I didn't expect that it would be completely off the IPv6 network.

Windows, Linux, iOS, and even my thermostats seem to have no trouble getting an address one way or the other (either via DHCPv6 or SLAAC or both) - what gives with Android and OpenWRT?  Has anyone successfully gotten an Android phone (of any version) on a local IPv6 network using OpenWRT, and if so, how?

In much confusion,

Rodney

(Last edited by rhester72 on 18 Nov 2014, 19:09)

Hmm with the defaults (your settings) it works fine for me with BB and trunk with Android 4.4.2 on a Note 3.
Android gets the RAs and assigns addresses and routes quite fine.

OpenWrt sends all sorts of stuff in its RAs including RDNSS and Search Domains however Android supports neither DHCPv6 nor reading RDNSS values from RAs (at least prior to 5.0) so it has to use the IPv4 DNS in any case.

However there are also known issues: https://code.google.com/p/android/issue … l?id=32662

I could help you debug this if you give me any more information. Is the RA incorrect in any way? Can you send me the tcpdump to cyrus-at-openwrt-dot-org ?

Sent as requested - hard to comment on the RA behavior, you'll understand why when you see the captures.

Thank you!

Rodney

It works perfectly for me in pure SLAAC mode, with the settings 'ra_management 0' and 'dhcpv6 disabled'.

You shouldn't really disable DHCPv6 totally. Setting ra_management is fine but disabling DHCPv6 will prevent Windows and others from getting IPv6 DNS servers.

I'll summarize my findings (and offer my tremendous thanks to CyrusFF for the pointers, patience and assistance!):

- Android is a tricky, tricky beast.  Near as I can tell, once the phone fails to receive a RA (for instance, if you've disabled it), it seems it will *never* accept a RA again until the phone is completely rebooted (restarting network services/reconnecting to the network will not help).  This is an Android-specific issue that has nothing to do with OpenWRT.

- Properly performing a tcpdump to capture RA traffic and IPv6 negotiation is also a bit tricky.  The following should do it:

tcpdump -n -i br-lan '(ether host <device MAC address> and not tcp) || (icmp6 && (ip6[40] == 133 || ip6[40] == 134 || ip6[40] == 135 || ip6[40] == 136))'

- All of my devices (Windows 7, Android, iOS, and Nest) seem to work perfectly fine with SLAAC only (i.e. no DHCPv6 IP address), but you want to keep DHCPv6 enabled if you want IPv6-listener DNS services (and please note that Android _will not_ accept IPv6 DNS information until Android 5, *period* - dnsmasq in OpenWRT will serve up AAAA records over IPv4 just fine, so no real concerns there).  If you want a SLAAC-only setup, the following will do it (in /etc/config/dhcp):

config dhcp 'lan'
        ...
        option dhcpv6 'server'
        option ra 'server'
        option ra_management '0' # Disable DHCPv6 address handouts, DNS only - i.e. "unmanaged" addressing/A-only

Note that the ra_management stanza must appear under "config dhcp 'lan'", *NOT* under "config odhcpd", even though it is a dhcpd-only option.

- A "phantom" additional IPv6 network may appear on your clients (but not your router!) - in my case, it's fd3f:9257:5a40::/64.  It is not a ULA network or anything created by the client.  This is harmless (there is no route) and appears to be an OpenWRT issue of some kind.  I believe it's being looked into.

Hope this helps someone!

Rodney

(Last edited by rhester72 on 14 Nov 2014, 04:03)

When I was digging into the packet dumps for openwrt's RA messages, they had a section with the DNS server in it. Are you saying that some systems will ignore that in the RA but not in a DHCP response?

     John

Yes, Windows only supports getting it from stateless or stateful DHCPv6. Android <5.0 supports neither of the two and always uses the IPv4 DNS, Android >= 5.0 supports RA DNS but not DHCPv6.

See the "ND RDNSS" column in http://en.wikipedia.org/wiki/Comparison … ng_systems for details.

Just if you were ever wondering why we have such strange defaults for IPv6 in OpenWrt...

That is actually an ULA as it begins with fd.... Does it match the ula_prefix in /etc/config/network? If so you can safely remove it there if it bothers you.

Strange - if you comment out ula_prefix, LuCI shows it as empty, but it still assigns one.  You have to actually explicitly set it to '' in order to truly disable it, it seems.  Thanks!

EDIT: Argh, I spoke too fast - even with ula_prefix set to '', it still creates one. 

Rodney

(Last edited by rhester72 on 14 Nov 2014, 14:19)

Taking a look at the netifd source (specifically interface-ip.c), the following appears to be the case:

- There is no ula_prefix defined, so it passes the if test and goes one level down
- The next check for ula_prefix fails, so interface_update_prefix is never called
- Despite the failure of the above check, interface_ip_add_device_prefix is called anyway - culling an address from...random memory?

I think that third one is where the problem is, and that function should be made part of the "if (ula_prefix)" check on line 994 instead of being blindly called regardless.

Perhaps this should be split into another thread, I'll leave that for the ops to decide.

Rodney

(Last edited by rhester72 on 14 Nov 2014, 19:43)

Spent a few more days chasing the 'phantom ULA' problem and I give up. 

Things I've seen:

- It actually has nothing to do with an empty ula_prefix - you can set a ULA, and you'll get it _plus_ the 'phantom' network (thus the issue isn't with interface-ip.c)
- I thought it may be related to ra_management being set to a value other than default, but it makes no difference what the setting is - the only way the phantom network doesn't show up is if you disable SLAAC altogether
- The phantom network does NOT appear as a network bound to any interface on the router, but DOES participate in router advertisements, thus propagating to the LAN (uselessly)
- The address of the phantom network is in the ULA range and is fixed (i.e. does not change on a specific router), but NOT the same range as the 'real' ULA (whatever it may be)
- The address also does not appear in NVRAM or any configuration file

Since it's not hurting anything (at least not readily apparent), I'm done chasing it - if anyone else wants to pick up the hunt, feel free. 

Rodney