Android (lack of) support for DHCPv6

Tony Hain alh-ietf at tndh.net
Wed Jun 10 16:13:18 UTC 2015


Ray Soucy  wrote:
> 
> Respectfully disagree on all points.
> 
> The statement that "Android would still not implement DHCPv6 NA, but it would
> implement DHCPv6 PD." is troubling because you're not even willing to
> entertain the idea for reasons that are rooted in idealism rather than
> pragmatism.

In Lorenzo's defense, I believe he is taking the long term pragmatic position, while you appear to be taking the short term idealistic position. 

For argument's sake... let's assume that a shiny new browser comes along the is designed to limit third party cross site correlation and tracking. It does this by using a different source address for every destination. This browser works fine on any network that allows N>1, but is stuck in the myopic historical world of older browsers on networks where N=1. To the pragmatism point, would you rather have a device like that do N NA requests (creating N ND state entries), or have it do PD (creating 1 ND + 1 Routing entry)?

Tony

> 
> Very disappointing to see that this is the position of Google.
> 
> 
> On Wed, Jun 10, 2015 at 10:58 AM, Lorenzo Colitti <lorenzo at colitti.com>
> wrote:
> 
> > On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy <rps at maine.edu> wrote:
> >
> >> Actually we do support DHCPv6-PD, but Android doesn't even support
> >> DHCPv6 let alone PD, so that's the discussion here, isn't it?
> >>
> >
> > It is possible to implement DHCPv6 without implementing stateful
> > address assignment.
> >
> > If there were consensus that delegating a prefix of sufficient size
> > via
> > DHCPv6 PD of a sufficient size is an acceptable substitute for
> > stateful
> > IPv6 addressing in the environments that currently insist on stateful
> > DHCPv6 addressing, then it would make sense to implement it. In that
> > scenario, Android would still not implement DHCPv6 NA, but it would
> > implement DHCPv6 PD.
> >
> > What needs to be gauged about that course of action is how much
> > consensus would be achieved, whether network operators would actually
> > use it (IPv6 has a long and distinguished history of people claiming
> > "I can't support
> > IPv6 until I get feature X", feature X appearing, and people changing
> > their claim to "I can't support IPv6 until I get feature Y"), and how
> > much of this discussion would be put to bed.
> >
> > That course of action would seem most feasible if it were accompanied
> > by an IETF document that explained the deployment model and clarified
> > what "sufficient size" is.
> >
> >
> >> Universities see a constant stream of DMCA violation notices that
> >> need to be dealt with and not being able to associate a specific IPv6
> >> address to a specific user is a big enough liability that the only
> >> option is to not use IPv6.
> >>
> >
> > It's not the *only* option. There are large networks - O(100k) IPv6
> > nodes
> > - that do ND monitoring for accountability, and it does work for them.
> > Many devices support this via syslog, even. As you can imagine, my
> > Android device gets IPv6 at work, even though it doesn't support
> > DHCPv6. Other universities, too. It's obviously  not your chosen or
> > preferred mechanism, but it does work.
> >
> 
> 
> 
> --
> Ray Patrick Soucy
> Network Engineer
> University of Maine System
> 
> T: 207-561-3526
> F: 207-561-3531
> 
> MaineREN, Maine's Research and Education Network www.maineren.net




More information about the NANOG mailing list