[180817] in North American Network Operators' Group
RE: Android (lack of) support for DHCPv6
daemon@ATHENA.MIT.EDU (Paul B. Henson)
Wed Jun 10 17:54:13 2015
X-Original-To: nanog@nanog.org
From: "Paul B. Henson" <henson@acm.org>
To: "'Lorenzo Colitti'" <lorenzo@colitti.com>
In-reply-to: <CAKGbBmmsDB6W_cxOYtbjuUuPgiJ1ONJzDQrrCj2khcTicXWJ6g@mail.gmail.com>
Date: Wed, 10 Jun 2015 14:43:00 -0700
Cc: 'NANOG List' <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> From: Lorenzo Colitti
> Sent: Wednesday, June 10, 2015 5:22 AM
>=20
> It's certainly a possibility for both sides in this debate to say "my =
way
> or the highway", and wait and see what happens when operators start
> removing support for IPv4.
You are rather confused.
Only one side of this debate is saying "my way or the highway" =E2=80=93 =
yours.
On my side, I am saying that it is my network, and it is not only my =
right but my responsibility to define policies as to how it should be =
used. That could be by blocking port 25 outbound to prevent spam abuse, =
or by forbidding unauthenticated wireless access points, or by requiring =
WPA2-enterprise authentication to connect, or any other technical =
configuration determined to be needed or desired by our policy. Can =
anyone reasonably say that a provider of a network is not allowed to =
determine the policies by which that network must be used 8-/?
On the other hand, *you* are providing infrastructure. You are refusing =
to implement agreed-upon Internet standards that are already widely =
supported. You are trying to determine what policy we should use on our =
network. It is completely different. I'm sorry you cannot see that.
> But even if you're dead set on using DHCPv6, what I don't see is why =
don't
> you support DHCPv6 PD instead of IA_NA?
Perhaps we will support it in addition to. Or perhaps we will not =
support it at all as that use pattern might not be desirable on our =
network. However, I am quite certain all of the equipment we purchase =
and recommend to purchase will support both standards, as well as SLACC =
and all other standards that have been defined as a base part of IPv6 =
support. As providers of infrastructure should. And then we will choose =
which of them to deploy. As managers of networks should.
> more than one IPv6 address and cannot be done without that. We know =
these
> will break today; tomorrow, we can use multiple addresses to do things =
we
> haven't thought of yet.
Who knows, maybe IPv12 will solve all of these issues? Maybe we =
shouldn't bother trying to deploy IPv6 while we're waiting for somebody =
to design and implement IPv12.
