[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Android (lack of) support for DHCPv6
- Subject: Android (lack of) support for DHCPv6
- From: sander at steffann.nl (Sander Steffann)
- Date: Wed, 10 Jun 2015 10:31:25 +0200
- In-reply-to: <CAKGbBmkE_AbZcmWhtWS68a=t9QmuccLdarhaN=m+9QEmJxOcJg@mail.gmail.com>
- References: <[email protected]> <CAKGbBm=dCDpeFJe4f0_KM6pjdvpeHrL4t7fyczOj2D3y=_07pg@mail.gmail.com> <1433905187.11511.25.camel@karl> <[email protected]> <1433907422.11511.30.camel@karl> <CAKGbBmkE_AbZcmWhtWS68a=t9QmuccLdarhaN=m+9QEmJxOcJg@mail.gmail.com>
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