Android (lack of) support for DHCPv6

Ray Soucy rps at maine.edu
Fri Jun 12 14:07:52 UTC 2015


The only thing I would add is that DHCPv6 is not just about "tracking"
clients.  Yes there are ways to do so using SLAAC, but they are not pretty.

Giving too much weight to tracking being the reason for DHCPv6 is just as
bad as giving too much weight to tethering as the reason against it.  It
skews the conversation.

For us, DHCPv6 is about *operational consistency*.

Universities have been running with the end-to-end model everyone is
looking to IPv6 to restore for a very long time.

When you connect to our network, wired or wireless, you get a public IP
with no filtering in place in most cases.

We have been living the end-to-end model, and that has given us operational
experience and insight on what it actually takes to support access networks
using this model.

Almost every peer institution I talk to has implemented custom systems
refined over decades to preserve the end-to-end model in a time of
increasing security incidents and liability.  These include IPAM systems,
which feed into vulnerability scanning, or host filtering for incident
response, etc.

These systems are in place for IPv4, and modifying them to support IPv6
(which most of us have done) is relatively easy in the case of DHCPv6.

By maintaining consistency between IPv4 and IPv6 we avoid having to retrain
hundreds of IT workers on supporting connectivity.  By saying that you
won't support DHCPv6, you effectively force us into a choice between
investing considerable effort in redesigning systems and training IT
personnel, while introducing confusion in the support process because IPv4
and IPv6 are delivered using completely different methods.

You have just made it cheaper for us to turn to NAT than to support IPv6.
That's unacceptable.

You might be thinking "well that's just universities and a small percent of
users", but the point here is that we do these things for a reason; we've
been living without NAT and our collective operational experience doing so
is something that would be wise to take into consideration instead of
dismissing it or trying to call us names.

Organizations running SLAAC who say everything is fine, think everything is
fine because IPv6 has received almost no attention from bad actors in terms
of security incidents or denial of service attacks.  Even well known
servers with IPv6 addresses on our network rarely see SSH attempts over
IPv6 today.

*This will fundamentally change as IPv6 adoption grows*.

Are you prepared to be able to deal with abuse reports of hosts on your
network participating on denial of service attacks?  Can you associate the
identity of a system to an individual when law enforcement demands you to
do so?  How much longer will it take you to track down a host by its IPv6
address to disable it?  How many other users have degraded service while
they're waiting for you to do that?

For most people that are used to the typical IPv4 model (NAT and open pool
DHCP), these events are very infrequent, so of course they don't get it.
For those of us running a more liberal network which preserves the
end-to-end model, free from aggressive filtering on user traffic, these
incidents are literally daily occurrences.

The fact is that you never know what service a user might enable on their
device only to be exploited and degrade service for their peers.

So yes, we are looking to the future in the case of DHCPv6, because we've
learned from the past.





On Fri, Jun 12, 2015 at 3:05 AM, <Valdis.Kletnieks at vt.edu> wrote:

> On Fri, 12 Jun 2015 02:07:22 -0000, Laszlo Hanyecz said:
>
> > > > university net nazis
> > >
> > > Did you really just write that?
> > >
> >
> > As far as "net nazi", I meant it in the same sense as a BOFH.  Someone
> who is
> > intentionally degrading a user's experience by using technical means to
> block
> > specifically targeted applications or behaviors.
>
> Well, which is more BOFH-ish:
>
> 1) We insist that you connect in a way that allows us to identify and track
> you for DMCA and other legal requirements that, quite frankly, we'd really
> rather not have to do, but it's a cost of doing business.
>
> 2) We don't let you connect at all because we can't do so without exposing
> ourselves to more legal liability than we want.
>
> Besides which, that's a total red herring.
>
> If you actually go back and *read*, I don't think anybody's "intentionally
> degrading by blocking targeted applications" - except those who are
> refusing
> to provide features to allow the applications to work on more network
> configs.
> The vast majority of us would *prefer* that Android got fixed so it can
> ask for
> more addresses and do more stuff. Most of us don't *care* if a user sucks
> up 13
> adresses across 4 devices at the same time - IPv6 addresses are *cheap*.
> On the other hand, covering your ass when a subpoena shows up and you
> realize
> you don't have the data needed to point at the user they're *really*
> looking
> for is incredibly expensive.
>
> OK? Let me say that again:  We're all asking Google to quit being stubborn
> and add a feature to Android so we can make the user experience *better*.
>
> Now who you calling a BOFH?
>
> > On the other hand, if it becomes common and acceptable to use DHCPv6 to
> > provide a single address only
>
> I encourage my competitor universities to design their networks that way.
> :)
>



-- 
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