[180731] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Android (lack of) support for DHCPv6

daemon@ATHENA.MIT.EDU (Sander Steffann)
Wed Jun 10 04:31:33 2015

X-Original-To: nanog@nanog.org
From: Sander Steffann <sander@steffann.nl>
In-Reply-To: <CAKGbBmkE_AbZcmWhtWS68a=t9QmuccLdarhaN=m+9QEmJxOcJg@mail.gmail.com>
Date: Wed, 10 Jun 2015 10:31:25 +0200
To: Lorenzo Colitti <lorenzo@colitti.com>
Cc: NANOG List <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org

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=3D1 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


home help back first fref pref prev next nref lref last post