[180780] in North American Network Operators' Group
RE: Android (lack of) support for DHCPv6
daemon@ATHENA.MIT.EDU (Tony Hain)
Wed Jun 10 12:13:23 2015
X-Original-To: nanog@nanog.org
From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Ray Soucy'" <rps@maine.edu>,
"'Lorenzo Colitti'" <lorenzo@colitti.com>
In-Reply-To: <CALFTrnM6BDWjLsSvDO4io70pWDL+Omf+VsSQML1nQS_SNRFWGQ@mail.gmail.com>
Date: Wed, 10 Jun 2015 09:13:18 -0700
X-SA-Exim-Mail-From: alh-ietf@tndh.net
Cc: 'NANOG List' <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Ray Soucy wrote:
>=20
> Respectfully disagree on all points.
>=20
> 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.=20
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=3D1. 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
>=20
> Very disappointing to see that this is the position of Google.
>=20
>=20
> On Wed, Jun 10, 2015 at 10:58 AM, Lorenzo Colitti =
<lorenzo@colitti.com>
> wrote:
>=20
> > On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy <rps@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.
> >
>=20
>=20
>=20
> --
> Ray Patrick Soucy
> Network Engineer
> University of Maine System
>=20
> T: 207-561-3526
> F: 207-561-3531
>=20
> MaineREN, Maine's Research and Education Network www.maineren.net
