Actually RFC 6434 explicitly states that there is no such requirement.

Android, AFAIK, isn't used for servers. That said, using DHCP to configure server IP addresses isn't recommended. What you want is to provision the server IP address using whatever orchestration software you use, so that it has the right address on startup.

Yeah, ND needs work, and is being worked on.

Actually I used to manage a very large IPv4 network. However, you are correct that I'd never managed an IPv6 network of any size when I was working on RFC 3315, and I don't think any of the other authors had either. And it shows--there are quite a few embarrassing holes in the spec. I'm not going to go down your "what keeps IPv6 from being adopted rathole," because from my perspective IPv6 _is_ being adopted, and I don't feel any need to see it adopted faster. I'm amazed at how much of the Internet I can reach over IPv6, and I'd like people to deploy carefully and correctly, not just think they're doing a drop-in replacement of IPv4 with IPv6 as if they were both the same thing.

Right. So what do you want to do with DHCPv6 that you can't do because Android doesn't support DHCPv6 IA_NA?

You aren't likely to notice them on a home network with network address translation. If you actually _use_ IPv6' capabilities, having to operate a DHCPv6 server is going to start to seem like a chore.

That's not how IPv6 works. You are trying to run an IPv4 network using the IPv6 transport. IPv6 is not just IPv4 with 2^96 more addresses.

There are no other hundred-ish host configuration variables in DHCPv6. There are two that you are likely to care about, and they're both also available in the RA.

I think you mean a stateless dynamic address, not a static address. Static addresses are manually configured, which nobody wants. RFC 7217 solves this problem by specifying a way of doing stateless auto-configuration without using the MAC address.

Anyone who wants privacy?

My Android phone works just fine on IPv6 networks.

Right, because peer-to-peer gaming is for losers, and nobody needs more than a few TCP or UDP ports per host, so multi-layer NAT is great, and will continue to limp boldly into the future.

At this point unless you are running an ancient version of your favorite operating system, RDNSS works fine. DNSSL is a Very Bad Idea, so you don't want your host to support that, but it probably does.

Not true. ICMPv6 router advertise messages can include DNS server addresses, and this works well. Populating hostnames in the local DNS using DHCP really hasn't caught on, even in IPv4. It's a neat hack, but hardly anybody uses it. DHCPv6 also lacks an authentication mechanism, although that's about to change, but in fact ICMPv6 has RA guard and SeND (Secure Neighbor Discovery). So you are exactly backwards on the authentication question.

IPv6 supports stateless IPv6 address assignment using SLAAC (StateLess Address AutoConfiguration). There is no need for a DHCP server. There are a number of reasons why using DHCPv6 to allocate individual addresses is a bad idea. If you've ever operated a DHCP server, you know about DHCP's failure modes, so I don't have to tell you. However, people get comfortable operating DHCP servers, and there's job security in it, so there are a lot of IPv4 old-timers who simply can't imagine a world without DHCP.

Speaking as one of the authors of RFC 3315, I think that Google is, if not right, at least not wrong. I would not personally want to have to set up a DHCPv6 server just to allocate individual IPv6 addresses. Talk about driving a nail with a sledgehammer. DHCPv6 is a great solution for the problem of configuring CPE routers with IPv6 prefixes. Addresses? Not so much.