We're in the beginning steps of bringing up IPv6 at the fairly large
university where I work. We plan to use DHCPv6 rather than SLAAC for a
variety of reasons. One of our guys recently noticed that Android has no
support for DHCPv6, and a rather odd issue thread discussing it:
https://code.google.com/p/android/issues/detail?id=32621
It looks like one developer simply refuses to implement it because if he
did there might be a scenario where somebody might not be able to tether
8-/? His attitude is that you have to use SLAAC and RDNSS, which we're
just not going to do. At this point I guess Android devices just won't
work with IPv6 on our network, and we'll suggest they complain to their
vendor and/or get a different phone.
I was just curious what this forum might think of that design decision
and the discussion on the issue thread.
Thanks...
We're in the beginning steps of bringing up IPv6 at the fairly large
university where I work. We plan to use DHCPv6 rather than SLAAC for a
variety of reasons. One of our guys recently noticed that Android has no
support for DHCPv6, and a rather odd issue thread discussing it:
Google Issue Tracker
It looks like one developer simply refuses to implement it because if he
did there might be a scenario where somebody might not be able to tether
8-/? His attitude is that you have to use SLAAC and RDNSS, which we're
just not going to do. At this point I guess Android devices just won't
work with IPv6 on our network, and we'll suggest they complain to their
vendor and/or get a different phone.
I was just curious what this forum might think of that design decision
and the discussion on the issue thread.
LC still has true religion. dump android.
'We plan to use DHCPv6 rather than SLAAC for a variety of reasons'
Care to elaborate on the reasons? Due to client support we have both. In fact we had SLAAC for many years and just 2 years ago we added DHCPv6 ..that was to ensure fuller client support (since windows and OSX amongst others started to support it) but also because of the ongoing slowness of our kit supporting the growing list of SLAAC extensions to provide DNS/NTP etc values 
dual-stack since 2001. HE 'sage' 
alan
curious about the reasoning, for what is probably singular devices on a LAN ?
Heh, there's a reason I said "variety" ;). Honestly, I'm like 90% systems
and 10% network, our network guys could probably better explain all of
the underlying thought process. My primary task on the deployment is
standing up the DHCPv6 servers and IPv6-enabling our operating systems
and applications. If you look at comment #101 on the issue thread,
that's actually from one of of network admins briefly discussing some of
the underlying rationale.
Thus spake Paul B. Henson (henson@acm.org) on Mon, Jun 08, 2015 at 08:14:54PM -0700:
We're in the beginning steps of bringing up IPv6 at the fairly large
university where I work.
Ditto.
We plan to use DHCPv6 rather than SLAAC for a variety of reasons.
Those reasons should probably be reviewed. The reality is that you will
probably need to support slaac, dhcpv6, and rfc6106.
"The nice thing about standards is that there are so many to choose from."
Dale
it seems as though the large concern is: "network gear wont' hand out
resolver data"
you'll have v6 and v4 right? dual-stack would let you still get dns
services over v4 while providing v6 transport as necessary/available.
there seem to be some other largely un-numbered concerns about 'router
management' ... but I'd submit that there are quite a few dual-stack
networks out there (campus and wide-area and consumer) and we're not
seeing this sort of problems supposed.
-chris
Lack of RDNSS support in Windows? That's the complication on my IPv6-only network.
Matthew Kaufman
As a general rule, Windows is a significant complication on any network forced to deal with its users.
This is not limited to IPv6.
Owen
It really is too bad. They're literally the only major player not on board
but claim to champion IPv6.
There is a big difference between saying that something isn't supported and
the Android position that they will NOT support DHCPv6. To me, that's
something that shouldn't be a decision they get to make, especially when
other operating systems have already come around with DHCPv6 support. Very
frustrating, and quite frankly an embarrassment to Google. I really didn't
expect that kind of dismissive response out of Lorenzo but maybe I just
haven't been paying attention.
Clients should support a verity of methods and let network operators choose
the solution that fits the environment. The whole premise for not
supporting DHCPv6 seems to be that mobile networks don't need it, but that
totally ignores 802.11 which is equally important.
Not to single out Google, on the opposite side It's equally disappointing
that Windows 10 will not support RDNSS (at least I haven't been able to
find any information on it, has anyone been able to confirm?).
I would hope we're past the religious arguments of SLAAC vs DHCPv6 but it
seems like every time the topic comes up the entire conversation turns into
a holy war on what method is the best. They're both valid, and both useful.
Hi,
supporting DHCPv6 seems to be that mobile networks don't need it, but that
totally ignores 802.11 which is equally important.
...and what about 802.3 for those Android boxes/systems on the wired? 
I would hope we're past the religious arguments of SLAAC vs DHCPv6 but it
seems like every time the topic comes up the entire conversation turns into
a holy war on what method is the best. They're both valid, and both useful.
agreed....too many times I find out that DHCPv6 is chosen as a stateful method
because they want to record/track MAC addresses like they do for DHCP.... a little
bit of explaining the protocol differences and they soon take up the SLAAC 
alan
i love this discussion. another enterprise wants to use ipv4 with
minimal change from ipv4, has problems, and the usual suspects tell
them to drink koolaid.
and we wonder at the pitiful ipv6 deployment.
randy
Hi,
and we wonder at the pitiful ipv6 deployment.
if more network admins actually did network stuff then IPv6
deployment would be plentiful and we could even start the
discussion about turning off IPv4....
alan
Agreed - apparently the solution is to implement SLAAC + DNS advertisements
*AND* DHCPv6. Because you need SLAAC + DNS advertisements for Android, and
you need DHCPv6 for Windows.
Am I the only one that thinks this situation is stupid?
Hi,
Agreed - apparently the solution is to implement SLAAC + DNS advertisements
*AND* DHCPv6. Because you need SLAAC + DNS advertisements for Android, and
you need DHCPv6 for Windows.
Windows has been dealing with SLAAC for ages...and OSX... DHCPv6 is
relatively new in that arena...
however in IPv6 your routers are sending RAs and can easily do prefix
annoucements etc anyway so SLAAC makes quite a bit of sense...allowing
the network to be more dynamic...no more having a gateway address
stuck in a DHCP config and all those statically addressed clients
needing to be changed etc.
i think we're looking at the wrong place...the issue isnt handing
out addresses.....its the large gaps in IPv6 functionality
at the edge versus whats in IPv4 space.... DHCP snooping, DAI,
ARP flood protection etc are getting pretty standard and solid...
FHS (first hop security) for IPv6 at the edge is often left wanting
(RA guard, ND/DAD protection etc)... but hey, we could get quite
active about the lack of multicast adoption across the internet too!
alan
If you think this is stupid, look in to the situation for modern WiFi and
Android.
https://code.google.com/p/android/issues/detail?id=17972
https://code.google.com/p/android/issues/detail?id=59502
https://code.google.com/p/android/issues/detail?id=62076
Summary:
- No 802.11k (though 802.11r in barely new devices)
- No DFS Channel support in Nexus-branded units, due to Google's resistance
to certification.
- Most WPA2-Enterprise schemes are sullied with warnings about traffic
being monitored as a response to private CAs being installed.
Windows support for enterprise features is downright stellar in comparison.
--Doug
Agreed - apparently the solution is to implement SLAAC + DNS advertisements
*AND* DHCPv6. Because you need SLAAC + DNS advertisements for Android, and
you need DHCPv6 for Windows.
Am I the only one that thinks this situation is stupid?
You don't need to hand out addresses by means of DHCPv6 IA_NA to windows, it does A=1 mode for SLAAC just fine.
There is a big difference between handing out resolver, ntp-server, dns search domains etc by means of DHCPv6, and handing out addresses based on DHCPv6 (stateless vs stateful).
From what I have understood Android has made design decisions that means
some things will break if you would only give is a single IPv6 address. This is most likely what some operators want to achieve when they say they want to use DHCPv6 IA_NA.
In order to actually solve the problem they're trying to solve, you need SAVI (https://tools.ietf.org/wg/savi/) and 802.1x (or similar mechanism) in order to actually gain the control these people are looking for. My question, do they implement this on IPv4?
I had this issue at the last NANOG meeting, I sometimes share my wifi with an embedded platform connected off my ethernet port, but I would get a message about how the Enterprise had disabled it. It wasn’t that important as in theory I could have the device join the local wifi directly but it would have been nice to not get that message from the network or the OS.
- Jared
It's indeed sub-optimal.
But that situation is far from the stupidest thing we've inflicted on ourselves,
and we've more or less survived them.
(I'm sure that we all have our diverging lists of "3 things stupider than
SLACC/DHCPv6" - this industry is old enough now to have quite the closet full
of stupidity skeletons....)
It’s way more fun to fight about it when NDP and DHCPv4 were coming of age at the same time, and DHCP was seen as only a minor upgrade to BootP at the time. The IPv6 purists seem to think that DHCP == NAT == EVIL at times which is frustrating.
The result is we have both M=0, M=1, etc.. options and something can be sent via NDP or DHCP, including possible DHCP-PD in conjunction.
The reality is I need things to “just work”. It was interesting to inherit someones half-done IPv6 implementation on our VPN platform, they didn’t understand that proxy-arp didn’t really exist in IPv6 land and the block had to be routed to the VPN box.
There are many minor and subtle differences in these technologies which become obvious when some time is spent digging through them.
- Jared