[141749] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Cutler James R)
Fri Jun 10 22:43:31 2011
From: Cutler James R <james.cutler@consultant.com>
In-Reply-To: <BANLkTi=whbvCKNLr5JtAkK=fxMnUyYZXxA@mail.gmail.com>
Date: Fri, 10 Jun 2011 22:43:24 -0400
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jun 10, 2011, at 10:21 PM, George Herbert wrote:
> On Fri, Jun 10, 2011 at 7:03 PM, Owen DeLong <owen@delong.com> wrote:
>>> And like I said before, we have more pressing things to do than =
tinker some more with DHCPv6.
>>=20
>> Meh... We can achieve a big win for relatively low cost very quickly =
and make IPv6 much
>> more palatable to a wide audience of enterprise administrators. I =
can't really say that there's
>> much more pressing than that. Yes, the issues you described above =
also fit into that category,
>> so, I'd say this is about equal.
>=20
> Right.
>=20
> Please, everyone - this is not just an "IPv4 way of thinking". This
> is different types of networks and network users.
>=20
> Just because your experience and your network don't have anything
> affected by these issues with DHCPv6 / RA doesn't mean that others
> don't.
>=20
> IPv6 adoption is driven by exhaustion, but it's limited by glitches =
like this.
>=20
>=20
> --=20
> -george william herbert
> george.herbert@gmail.com
>=20
This is "different types of networks and network users" and also =
different operational, administrative, and security domains.
I am also getting frustrated with the endless discussions that could be =
immediately shortened by "tinkering with DHCP" to add one or two =
additional options -- a minimal cost process. Why is the argument not =
about business needs instead of technical purity?
See these quotes from 2009 and let us collectively get off the dime!
On Oct 22, 2009, at 3:03 PM, Vasil Kolev wrote:
> =D0=92 11:10 -0700 =D0=BD=D0=B0 22.10.2009 (=D1=87=D1=82), Owen DeLong =
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>> OK... Here's the real requirement:
>>=20
>> Systems administrators who do not control routers need the ability in =
a dynamic host configuration mechanism to assign a number of parameters =
to the hosts they administer through that dynamic configuration =
mechanism. These parameters include, but, are not limited to:
>>=20
>> 1. Default Router
>> 2. DNS Resolver information
>> 3. Host can provide name to server so server can supply =
dynamic DNS update
>> 4. IP Address(es) (v4, v6, possibly multiple v6 in the case =
of things like Shim6, etc.)
>> 5. NTP servers
>> 6. Boot server
>> 7. Site specific attribute/value pairs (ala DHCPv4 Options)
>>=20
>> These assignments MUST be controlled by a server and not by the =
router because the router is outside of the administrative control of =
the Systems Administrator responsible for the hosts being configured.
>=20
>=20
> And to add a real-world case for this - two months ago at HAR (hacking =
at random, a convention in the Netherlands) I was in the network team, =
handling fun stuff like DHCP servers, DNS, etc.. We also provided IPv6 =
connectivity there (we had a /16 IPv4 zone and a /48 IPv6 zone), and at =
some point we asked the question around - ok, how should we provide DNS =
and other useful information for the V6 only people?
>=20
> After a while with all the brains around, the decision was to write it =
on the datenklos through the field, where people can read it and =
configure it in their browsers. This would've been funny if it wasn't so =
sad.
>=20
> OTOH, for V4 everything with the DHCP worked fine (as it has always =
done, even at an event of this size), as is my experience with all the =
networks I've administered. Saying that DHCP doesn't work for me is =
extremely weird, as to me this means someone made specific effort to =
fuck it up.
>=20
> Finally - we have something that works, that's called DHCP. It might =
not be perfect, it might have some weird issues and implementations, but =
it's actually making our lives easier, is tested and works. I'd love =
anything that would be better, but as an option, not as the only choice =
I have. And it's not just the protocol that I care about. I care about =
that it's implemented in a HOST, where I can play with the software as =
much as possible, instead on a ROUTER, which is a vastly different =
device with
> rarely-updated OS, and even in the case where they're both the same =
machine(as in small office environments), they're again handled at =
different layers (kernel vs userspace). There are reasons that we're =
using what we're using, and not all of =20
> them are "because we're masochistic idiots".
> --=20
> Regards,
> Vasil Kolev
Following on the comments above:
The security domain for HOST should not overlap the security domain for =
ROUTER.
That is the primary driver of the separate administration of HOST and =
ROUTER. Heaven help us if the latest M$ virus, or even =
social-engineering distributed malware began to affect BGP!
Give the router managers the NTP server addresses and their DHCP =
forwarding list and leave them alone to produce a robust and reliable =
transport facility!
James R. Cutler
james.cutler@consultant.com
