Android (lack of) support for DHCPv6

Fri Jun 12 15:58:24 UTC 2015

Personally my view is that DHCPv6-PD support would be much better for
tethering, but I don't get to tell Google how to do that just like they
don't get to tell me how to give out addresses.  My only request would be
if you do implement DHCPv6-PD for tethering, please make it only request a
prefix when you actually enable tethering, not as the default.  That would
be bad for different reasons.

Wouldn't the simple play here be for Android to just throw up a message
saying "This network does not support tethering" if SLAAC isn't enabled,
and to let users complain to local operators if that's something they
want?  Google doesn't get blamed, operators are happy, and ultimately users
have a better experience because the expectations of the network are clear
rather than trying something that will likely not work consistently across
networks.

If the concern is that you don't want to carriers to use DHCPv6 then you
could just limit it to 802.11.

The point is that there are several options here to address peoples
concerns and make IPv6 adoption that much easier, but the position of
Google on DHCPv6 support for Android is just another barrier to widespread
adoption of IPv6.  I honestly appreciate the work Google has been doing for
years to promote IPv6 adoption, but they're wrong here.

On Fri, Jun 12, 2015 at 11:30 AM, Todd Underwood <toddunder at gmail.com>
wrote:

> lorenzo already stated that the cost was in user satisfaction related to
> tethering and the business reason was the desire to not implement NAT in v6
> on android.
>
> many people didn't like those reasons or think that they are less
> important than their own reasons.
>
> shockingly, everyone believes that their own priorities are more important
> than everyone else's priorities.
>
> the 'cranky about the lack of DHCPv6' crowd has already made their points
> and further shut down conversation by demanding that lorenzo speak for
> Google on this thread.  indeed, shouting loudly and shutting down
> conversation was almost certainly the intent of many of the posts here.  so
> mission accomplished.
>
> fists have been pounded.  conversation has been halted.  well done.
>
> can me move on now?
>
> t
>
> On Fri, Jun 12, 2015 at 11:18 AM, James R Cutler <
> james.cutler at consultant.com> wrote:
>
>> Ray Soucy has given us an nice summary. It goes along with “please let me
>> manage my business and don’t take away my tools just to satisfy your
>> prejudices.”
>>
>> Selection of management policies and implementations is ALWAYS a local
>> issue (assuming consideration of legal necessities). Especially in the
>> end-to-end model, the requirements management of end systems has not
>> changed because the IP layer protocol has changed. This is a good reason
>> for not prohibiting continuing use of DHCP-based solutions. “Purity of
>> protocols” is not a reason for increasing management costs such as
>> described by Ray.
>>
>> This debate about DHCPv6 has been going on far too long.  I want to know
>> how much it will cost the “SLAAC-only” faction to quit fighting DHCPv6.
>> My conjecture is that it would be minimal, especially as compared to the
>> costs for the activities described by Ray.
>>
>> Putting it differently: What business purpose is served by fighting
>> full-functioned DHCPv6 deployment. Don’t give me any RFC or protocol
>> arguments - just tell me the business reasons for forcing others to change
>> how they manage their business.
>>
>> James R. Cutler
>> James.cutler at consultant.com
>> PGP keys at http://pgp.mit.edu
>>
>>
>>
>> > On Jun 12, 2015, at 10:07 AM, Ray Soucy <rps at maine.edu> wrote:
>> >
>> > 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
>>
>>
>

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