Comment 1 for bug 849994

I ran tests on all of the following setups:
 - Single-stack SLAAC IPv6 network (with RDNSS and DNSSL)
 - Single-stack stateful DHCPv6 IPv6 network
 - Single-stack stateless DHCPv6 IPv6 network
 - Single-stack DHCPv4 IPv4 network
 - Dual-stack SLAAC IPv6 (with RDNSS and DNSSL) and DHCPv4 IPv4 network
 - Dual-stack stateful DHCPv6 IPv6 and DHCPv4 IPv4 network
 - Dual-stack stateless DHCPv6 IPv6 and DHCPv4 IPv4 network

I didn't see any regression, only limitation is "DNSSL" not working with SLAAC but that's not a regression, just another Network Manager bug :)

This change was done following a discussion I started on the Network Manager mailing list regarding non-compliance of their DHCPv6 support with the RFC.

E-mail discussion can be found at: http://mail.gnome.org/archives/networkmanager-list/2011-July/msg00189.html

As was mentioned in my e-mail, the above fix makes DHCPv6 respect section 9 of RFC 3315:
   The DUID is carried in an option because it may be variable length
   and because it is not required in all DHCP messages. The DUID is
   designed to be unique across all DHCP clients and servers, and stable
   for any specific client or server - that is, the DUID used by a
   client or server SHOULD NOT change over time if at all possible; for
   example, a device's DUID should not change as a result of a change in
   the device's network hardware.

This change is required for any IPv6 setup where you want to push per-client configuration which is extremely common setup.

The current behaviour gives you a different DUID per connection in a non-deterministic way so a DHCPv6 server administrator has effectively no way to assign per-client configuration. Also, should you be connected to the same network through two different network cards (wired + wireless) you'll be getting two different IPv6, making you loose your connections should your primary one (wired usually) get disconnected.