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 <lore...@colitti.com> > wrote: > > > On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy <r...@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