The stupidity of trying to "fix" DHCPv6

Cutler James R james.cutler at consultant.com
Fri Jun 10 21:43:24 CDT 2011


On Jun 10, 2011, at 10:21 PM, George Herbert wrote:

> On Fri, Jun 10, 2011 at 7:03 PM, Owen DeLong <owen at delong.com> wrote:
>>> And like I said before, we have more pressing things to do than tinker some more with DHCPv6.
>> 
>> 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.
> 
> Right.
> 
> Please, everyone - this is not just an "IPv4 way of thinking".  This
> is different types of networks and network users.
> 
> 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.
> 
> IPv6 adoption is driven by exhaustion, but it's limited by glitches like this.
> 
> 
> -- 
> -george william herbert
> george.herbert at gmail.com
> 

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:
> В 11:10 -0700 на 22.10.2009 (чт), Owen DeLong написа:
>> OK... Here's the real requirement:
>> 
>> 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:
>> 
>> 	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)
>> 
>> 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.
> 
> 
> 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?
> 
> 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.
> 
> 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.
> 
> 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  
> them are "because we're masochistic idiots".
> -- 
> 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 at consultant.com








More information about the NANOG mailing list