Re: Android (lack of) support for DHCPv6

[Matthew Huff <mhuff () ox com>]

+1

One IP per device will almost most likely be the preference and implementation in corporate/enterprise deployments. Too 
much procedure, regulation and other roadblocks prevent any other solution.

Authentication, Authorization, Accounting, ACLS, NMS, IDS, IP management, custom software, and other roadblocks will 
certainly stall if not stop IPv6 deployments in enterprises if there isn’t at least the choice of static, single IPv6 
addresses per device. SLAAC will probably be a complete non-starter in many corporate environments. It is in ours. The 
more ideologues preach about restoring peer-to-peer connectivity, dynamic IPs, privacy addresses, etc… the less 
penetration IPv6 will happen in corporate networks.



> On Jun 10, 2015, at 2:11 PM, Ray Soucy <rps () maine edu> wrote:
>
> I've already written systems to do this kind of thing, but the logging
> requirements quickly go through the roof for a non-trivial network;
> especially in the case of temporary addressing now default on many
> systems.  That isn't so much the issue as operational consistency and
> supportability.
>
> The requirement for hosts to be dual stack will exist for some time.
>
> For the sanity of IT workers and users alike (most of which don't really
> know the details of IPv6 and barely understand address scopes let alone
> multiple addresses) there needs to be some level of consistency between how
> hosts are addressed and communicate between the two protocols.  Saying
> we'll develop one system for IPv4 and one for IPv6 ultimate results in
> "Let's not deploy IPv6 just yet".
>
> This rings especially true when security concerns come up.  Consistency
> between IPv4 and IPv6 needs to be possible in this transition period, or
> people simply decide to not deploy.  Consistency in addressing and
> maintaining a one host one address model has major implications for policy
> construction, flow analysis and incident response, denial of service
> mitigation, etc.  If the consistency isn't there, you need to "re-invent
> the wheel" for every aspect, then maintain different systems for IPv4 and
> IPv6 along side one another.
>
> Even worse, if we keep seeing adoption held up by inconsistent client
> implementations I fear we'll start seeing commercial products which NAT or
> proxy IPv4 to IPv6 to avoid using IPv6 internally.  It's very ugly and
> requires some DNS magic to work, but it's not impossible.  We're already
> seeing this in terms of cloud computing and virtualization.  Servers have
> IPv4 addresses and only a load balancer with an external IPv6 address.
>
> We absolutely need to make it possible for people to adopt IPv6 before we
> can reach a point where IPv4 can go away, and for some organizations the
> answer of "Just use SLAAC" is simply not acceptable.
>
> They just won't do it.
>
> Preventing IPv6 adoption hurts us all.  And Android not supporting a MAJOR
> part of IPv6 like DHCPv6 is preventing adoption.
>
>
>
>
>
> On Wed, Jun 10, 2015 at 1:42 PM, Sander Steffann <sander () steffann nl> wrote:
>
> > > 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.
> >
> > /me starts to write that whitepaper that educates people on how to do this
> >
> > Cheers,
> > Sander
>
>
> -- 
> 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