I wrote a patch to handle DHCPv6 DUIDs properly in NetworkManager; ideally this should be shipped with NM in Oneiric to properly support multiple interfaces getting consistently the same DUID across multiple DHCP requests; which should allow multiple interfaces to get the same IPv6 address if they are on the same network.
The patch is relatively simple and watches the DUID already provided by dhclient if it's available and attempts to make sure it is recorded in the future lease files when necessary. If the DUID isn't present anywhere, it will be generated as a DUID-LLT, and the values from dhclient always takes precedence.
An experimental package has been built in my PPA for testing. Testing was done and completed successfully across different permutations of DHCPv6, DHCP, SLAAC, etc. with no adverse effects.
https://launchpad.net/~mathieu-tl/+archive/nm/+sourcepub/1919157/+listing-archive-extra
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://
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.