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