DHCPv6-4.1.mumble

[Ted Lemon]

On Jun 12, 2008, at 1:22 PM, Evan Hunt wrote:
> Out of curiosity, what are these advatages?

Clarity, simplicity, interoperability...

Right now, what the DHCPv4 spec says is, "here is how you configure a  
stack for IPv4."   What the DHCPv6 spec says is "here's how you  
configure a stack for IPv6."   What Bill is proposing is that DHCPv4  
be changed to say "here's how you configure a stack for IPv4, and by  
the way here are some IPv6 thingies too."   It doesn't say what to do  
if you get different IPv6 values from DHCPv6.   It doesn't say what to  
do if you don't find yourself with any IPv6 RA messages.   Etc.

Of course it could be made to work, but it's not clear to me that it'd  
be worth the effort, since the primary reason for doing it is to avoid  
having to run a DHCPv6 client.

If you just listen to Bill's statement about what his network  
environment will be like if he hacks around this, I think it comes  
clear: god help you if you aren't running the locally-hacked DHCP  
client.   Of course, if there were a standard, you could come  
prepared, but why would anybody bother to implement to this new  
standard when there are existing choices that work just as well, and  
when implementing the new standard makes the decision as to which  
configuration information to use more, not less, complicated?

If Bill were to simply set up DHCPv4 and DHCPv6 service on his  
network, and run a stateless DHCPv6 client on his client machines,  
then anybody else who came to his network, running this standard  
solution, would also be able to interoperate correctly.