To this time of writing The Android AOSP Team still refuses to adopt DHCPv6. Lorenzo (one of the team) agreed to a commenter that IPv6 should not be treated equivalently as IPv4 with more bits.
> Lorenzo (one of the team) agreed to a commenter that IPv6 should not be treated equivalently as IPv4 with more bits.
Judging by the list of standardized IPv6 Neighbor Discovery Option types, https://www.iana.org/assignments/icmpv6-parameters/icmpv6-pa..., it seems like that's exactly what is happening. Not only does that list make it seem like RA/ND ICMP messages are being used/abused to mirror 1:1 their DHCP field counterparts, but several of those RFCs define RA/ND and DHCPv6 options together.
I'm curious: what sort of meaningful network management possibilities, beyond stateless addressing, are made practical with RA/ND that aren't with DHCPv6, especially considering that stateless DHCPv6 is a thing? At first I thought it might be easier to relay/passthrough specific extensions, but a cursory reading of RFC 4861 (Neighbor Discovery) makes me think you can aggregate these options in the same packet, in which case it would be no more easier (from the perspective of implementations) to selectively relay these configuration parameters than with DHCPv6. And if I'm also reading RFC 3315 (DHCPv6) correctly, ND is an even better DHCP as solicitors/requesters can selectively query specific options rather than the advertisers/responders having to send all options down in the same reply.
If RA/ND is already being used/abused this way, why would people dislike DHCPv6 on principle, as opposed to disliking DHCPv6 as unnecessarily duplicative (notwithstanding that it came before most of these ND options). If anything I would think such people would be advocates for DHCPv6 if they were afraid of ND becoming a dumping ground for extensions unrelated to fundamental addressing and routing issues.
