On Fri, Dec 23, 2011 at 12:19:53AM -0800, Doug Barton wrote: > Wrong answer. The right answer is for DHCPv6 to be a superset of RA so > that organizations that need more than RA provides only have to run > DHCP. As a free bonus, it's FAR easier to add one knob (default route) > to DHCPv6 than it is to add all features to RA. Extra bonus, the only > hurdles are political, not technical.
I agree with your essential point, except to say that for me to be happy with DHCPv6, I also want to be able to assign an address to a host by taking some constant bit of information from the host (like, say, a MAC address) and know that no matter how I reinstall that host, it'll retain the address I gave it. As it is today, to use DHCPv6 the way I want, I must first have my host get an IP (the wrong one), figure out what DUID it used, and reconfigure my server to give it the one I want it to have. With RA, I don't assign the address, but to know what it is, I just look up its MAC address and I'm done. With DHCPv4, I look up its MAC address, add it to my server configuration and I'm done. I don't really care if it's a MAC address per se, but I don't want to have to deal with DUID change because of OS reinstallation, change of client software, dual-boot, removal & re-adding of the connection definition, etc. I can think of reasons why it might be nice to have different DUIDs for different OS's, so I don't object to the option, but in most cases the current spec hurts (me) more than it helps. -- Scott Schmit
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
