[180795] in North American Network Operators' Group
RE: Android (lack of) support for DHCPv6
daemon@ATHENA.MIT.EDU (Tony Hain)
Wed Jun 10 14:36:16 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: <CALFTrnMocLuLBw8q5_MkZCq0d0-cJddXd6sNwFnbw_N-JACwHQ@mail.gmail.com>
Date: Wed, 10 Jun 2015 11:36:05 -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:
> I don't really feel I was trying to take things out of context, but =
the full quote
> would be:
>=20
> "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."
>=20
> To me, that's essentially saying:
>=20
> "EVEN IF we decided to support DHCPv6-PD, and that's a big IF, we will =
never
> support stateful address assignment via DHCPv6."
>=20
> This rings especially true when compared against the context of =
everything else
> you've written on the subject.
>=20
> I think that's how most others on this list would read it as well.
>=20
> If that isn't what you meant to say, then I'm sorry. I'm certainly =
not trying to put
> words in your mouth.
>=20
> I still feel that it's a very poor position to take.
>=20
> Given that you don't speak for Google on the subject, if you're not =
the decision
> maker for this issue on Android, could you pull in the people at =
Google who are,
> or at least point us to them?
>=20
> A lot of us would like the chance to make our case and expose the harm =
that
> Android is doing by not supporting DHCPv6.
>=20
> I think the Android team is very overconfident in their ability to =
shape the
> direction of IPv6 adoption, especially with years old Android releases =
being still
> in production and it taking incredibly long for changes to trickle =
down through
> the Android ecosystem.
>=20
> That delay is also why we have a hard time accepting the mindset that =
IF you
> see a need for it in the future you'll add it. That will be 4 to 8 =
years too late.
>=20
>=20
>=20
So the flip side of that point is; how many decades does it take to =
trickle things through the operational networks? Having seen this first =
hand at the operator, infrastructure vendor and OS vendor perspectives, =
the general network operations community considers anything that makes =
Application Development harder to be "their problem". Persistent =
messages like "don't waste time on IPv6 development because we are only =
going to deploy IPv4 and I need shiny feature X NOW" caused at least =
one decade of delay in infrastructure products doing anything. Now we =
appear to be stuck in another decade of delay based on "it is not =
exactly the same as IPv4".=20
Like it or not, the OS vendors actually cater to the Application =
Developers, as they are the ones that produce something useful to the =
end user. Their job is to be the intermediary between the needs of the =
apps, and the availability (or lack) of network resources. (FWIW: as =
much as people on this list don=E2=80=99t like them this is exactly why =
I made sure XP did automated IPv6 over IPv4 tunneling) Fault the OS =
vendors if you want to, but they are often trying to make the networks =
appear more capable and consistent than they really are. To a first =
order this is the primary "innovation" of the iPhone, in telling the =
carriers "no you don't get to fragment the OS or application =
functionality".=20
At the end of the day though, N =3D 1 is the most likely result of an NA =
deployment today. Once that engrained in the next generation of network =
operators, they will do everything they can to resist change, because =
their security architecture and all their tools assume N =3D 1 (or are =
we already there?). Taking the opportunity of change to also change the =
mindset toward PD allows N > 1. Enforcing an NA model where N > 1 =
eventually fails as N blows out the ND cache.=20
Tony
>=20
>=20
> On Wed, Jun 10, 2015 at 12:29 PM, Lorenzo Colitti =
<lorenzo@colitti.com>
> wrote:
>=20
> > On Thu, Jun 11, 2015 at 12:36 AM, Jeff McAdams <jeffm@iglou.com> =
wrote:
> >
> >> Then you need to be far more careful about what you say. When you
> >> said "Android would still not support..." you, very clearly, made a
> >> statement of product direction for a Google product.
> >
> >
> > Did you intentionally leave the "in that scenario," words that came
> > right before the ones you quoted?
> >
> > How does a sentence that says "in that scenario, android would <X>"
> > constitute a statement of direction?
> >
>=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
