v6 & DSL / Cable modems

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.

	Cutler

On Feb 6, 2009, at 12:22 PM, sthaug at nethelp.no wrote:

>> The problem is that DHCP seemed like a good idea at the time but it
>> doesn't make any sense today. We know that parsing complex binary  
>> data
>> formats is asking for security problems.
>
> And parsing complex text data structures is better?
>
>> What we need is a simple, fast, efficient way to distribute the basic
>> information that a host needs to start sending and receiving packets
>> and a pointer to a place where additional location dependent
>> configuration information can be found. That would be: address 
>> +prefix,
>> gateway and (arguably) DNS and then something like a URL for a server
>> that has the config info. The system and applications can then load
>> information from the config server over HTTP in XML format or some  
>> such.
>
> No, this information must be available in *one* place. It's called a
> DHCP server. As an operator, this is clearly what I want, both for  
> IPv4
> and IPv6.
>
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
>

James R. Cutler
james.cutler at consultant.com