Hi Lorenzo,
It's certainly possible to make Android request N IPv6 addresses via DHCPv6, and not accept the offer if it is offered fewer than N addresses. But that only really makes sense if there's a generally-agreed upon minimum value of N. I'd be happy to work with people on an Internet draft or other standard to define a minimum value for N, but I fear that it may not possible to gain consensus on that.
I definitely think we should start pushing for N>1 because that will really hurt IPv6 in the future. However any fixed N is a potential danger as requirements will change in the future. But maybe we can do something smarter here.
It's also possible for Android to support DHCPv6 PD. Again I'd be happy to work with people on a document that says that mobile devices should do DHCPv6 PD and not DHCP NA, and then implement DHCPv6 PD. But I fear similar arguments will be had there.
I think this will be more difficult to get consensus on, and I can also see more deployment issues (much more state in the routers for all those PDs, needing huge amounts of /64s (or larger) to be able to deal with a few hundred/thousand clients) but it would be very nice if this was possible :)
Asking for more addresses when the user tries to enable features such as tethering, waiting for the network to reply, and disabling the features if the network does not provide the necessary addresses does not seem like it would provide a good user experience.
I don't think it is unreasonable. If the network doesn't support the features you need then let the user know (grey out the feature and add a note that says "broken network"). It will put pressure on the network department to fix their DHCPv6 implementation. I have read Lorenzo's arguments and while I don't agree with all of them I do see the risk of creating a situation where N=1 is the default. That would be bad. But instead of not supporting DHCPv6 I think we should work on making sure N>>1. Cheers, Sander