The Business Wisdom of trying to "fix" DHCPv6

Cutler James R james.cutler at
Sat Jun 11 02:51:26 UTC 2011

> James R. Cutler james.cutler at 
> Fri Feb 6 18:00:52 UTC 2009
> DHCP items are end system considerations, not routing network  
> considerations.
> The network operations staff and router configuration engineers do not  
> generally concern themselves with end systems.
> End systems generally are managed quite independently from the routing  
> network. And, they are more subject to the vagaries of day to day  
> business variability. Note the "one place" in the quoted message below.
> The only overlap is broadcast forwarding for DHCP initiation.
> Besides, configuration control is hard enough for router engineers  
> without adding the burden of changing end system requirements.  Adding  
> the forwarding entries is almost too much already! ;)
> So, for routing network operators to denigrate DHCP is probably due to  
> lack of consideration of the end user system requirements.  And those  
> who denigrate DHCP and say "just hard code it" make end system  
> management that much more difficult.
> I still conclude that DHCP is a useful tool for both IPv4 and IPv6  
> systems.

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

James R. Cutler
james.cutler at

More information about the NANOG mailing list