No, it is LESS robust, because the client identifier changes when the SOFTWARE changes. Around here, software changes MUCH more often than hardware. Heck, even a dual-boot scenario breaks the client identifier stability. Worse yet, DHCPv6 has created a scenario where a client's IPv4 connectivity and IPv6 connectivity break under /different/ scenarios, causing difficult-to-troubleshoot half-connectivity issues when either the hardware is replaced or the software is reloaded.
Any client whose DUID changes on software re-install has a very poor choice of default DUID and should be configurable for a better choice of DUID. That is not DHCPv6�s fault.
It is reality. DHCPv6 needs to take reality into account. DHCPv6 as defined in RFC 3315 does not offer client MAC address at all (thus making the job more difficult for a number of organizations). All I've seen so far indicates that this was a deliberate choice by the DHCPv6 designers, and in my opinion a very poor one. Fortunately we now have RFC 6939 (DHCPv6 Client Link-Layer Address Option), and we're waiting for vendors to implement this. That solves one half of the problem. The other half is to actually let the DHCPv6 lease be based directly on the MAC address. The language in RFC 3315, as I read it, makes this difficult or impossible. Steinar Haug, Nethelp consulting, sthaug@nethelp.no