[180942] in North American Network Operators' Group
Re: Android (lack of) support for DHCPv6
daemon@ATHENA.MIT.EDU (James R Cutler)
Fri Jun 12 11:18:38 2015
X-Original-To: nanog@nanog.org
From: James R Cutler <james.cutler@consultant.com>
In-Reply-To: <CALFTrnM5zMgkHsWmPpc+gdYbjHyM4beaH9+5WrfBu-kHVd0P3Q@mail.gmail.com>
Date: Fri, 12 Jun 2015 11:18:21 -0400
To: Ray Soucy <rps@maine.edu>,
NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--Apple-Mail=_06406564-7347-4AB9-AF71-3004E1AE3283
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Ray Soucy has given us an nice summary. It goes along with =E2=80=9Cplease=
let me manage my business and don=E2=80=99t take away my tools just to =
satisfy your prejudices.=E2=80=9D
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. =E2=80=9CPurit=
y of protocols=E2=80=9D 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 =E2=80=9CSLAAC-only=E2=80=9D 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=E2=80=99t 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@consultant.com
PGP keys at http://pgp.mit.edu
> On Jun 12, 2015, at 10:07 AM, Ray Soucy <rps@maine.edu> wrote:
>=20
> 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.
>=20
> 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.
>=20
> For us, DHCPv6 is about *operational consistency*.
>=20
> Universities have been running with the end-to-end model everyone is
> looking to IPv6 to restore for a very long time.
>=20
> When you connect to our network, wired or wireless, you get a public =
IP
> with no filtering in place in most cases.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> You have just made it cheaper for us to turn to NAT than to support =
IPv6.
> That's unacceptable.
>=20
> 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.
>=20
> 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.
>=20
> *This will fundamentally change as IPv6 adoption grows*.
>=20
> 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?
>=20
> 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.
>=20
> 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.
>=20
> So yes, we are looking to the future in the case of DHCPv6, because =
we've
> learned from the past.
>=20
>=20
>=20
>=20
>=20
> On Fri, Jun 12, 2015 at 3:05 AM, <Valdis.Kletnieks@vt.edu> wrote:
>=20
>> On Fri, 12 Jun 2015 02:07:22 -0000, Laszlo Hanyecz said:
>>=20
>>>>> university net nazis
>>>>=20
>>>> Did you really just write that?
>>>>=20
>>>=20
>>> 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.
>>=20
>> Well, which is more BOFH-ish:
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Besides which, that's a total red herring.
>>=20
>> 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.
>>=20
>> 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*.
>>=20
>> Now who you calling a BOFH?
>>=20
>>> On the other hand, if it becomes common and acceptable to use DHCPv6 =
to
>>> provide a single address only
>>=20
>> I encourage my competitor universities to design their networks that =
way.
>> :)
>>=20
>=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
--Apple-Mail=_06406564-7347-4AB9-AF71-3004E1AE3283
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.27
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVevhCAAoJEFTPx1V3wJTL/AcP/R25VK3mMvmhdaT9mGVI+mQH
De4ZkzpogGtnzAoUNltSqhOoQl2OBFv43x7T5Qtk8WHG/1B4I+GTQZIsB2NmzJSP
VrWlgkjsYCrYsBQ0LlqQmBjXKETIspzrQAPYMJ1LXazKwxpMaQwJN+jJuK0dDDGV
P6YwAIiyISS5jYASJ2wlHIjQ5K+QpfuUuX66IctVxQFXmyqzbve5v/08P13MKatY
J3i6vhgBYK7DhoLhAphfXJYaAQbLY32HKOtuUGo3LQZoppWSqONzFG3ThbewYvlC
E2+NnVj7uwWN9Op5DAS2E6l/2g36LzfzLt9Gx0dU/OpeASpzh4gIprERlWFSfZ4o
4zYQCXR7rOw8uanu2w49yD1LWPvfksaGh00VA/yImpcpdpkPGH1spDB8lOniaj4u
O+Pt1DvGEKBqJsq4CKuZmVmWiHsNLKd9CATsnP8bCD3BY+dVn7jNJ8aynqwntlBg
PgcCT1VqAcIL00ciNY0iTvmNrKrTljFjO9Ch94/FY7L0h/4DWfdRzU13VdI0a95x
OgsjO7tqcE3kukD5vuL8T5QPpR6Ol+x6AJXp+sxbv+FUjoNNXDpzI145jG/i+mo7
Ta9hOs5VZ/7bx1bShyzMmWt9gcXvF5Pc8VghQ9Y5Yh7AW8LBy/WnRVs40qJ8olul
wAP6QaQQnBSyblfGmap6
=07OU
-----END PGP SIGNATURE-----
--Apple-Mail=_06406564-7347-4AB9-AF71-3004E1AE3283--
