This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
release.

dhcp6c was saving the DUID when one was initially generated, but not any on
received messages. I have patched the code so that the received DUID-LLT is
saved to the DUID_FILE in /var/lib, which should maintain a consistent DUID
across reboots.
Attaching the patch to this bug report.

In order to debug this problem, we need the test case for RHEL 5.2 with an exact
reproducer, including output with verbose debugging messages from the DHCPV6
software. One way to do this would be to extract the commands that TAHI runs.
The man pages for dhcp6s, dhcp6r, and dhcp6c all show how to generate verbose
debug messages.

When the NUT reboots, is the /var/lib/dhcpv6 directory getting cleared out before starting dhcp6c again?
The DUID is recorded as /var/lib/dhcpv6/dhcp6c_duid, so the only way to keep it persistent is to make
sure that file isn't removed. Any time it's removed, a new DUID will be generated by the client.

Is this still happening in RHEL 5.2 or the 5.2.z update? I'm pretty sure all of the instances where the DUID
needs to be written out are in the code, but I may have missed one. Please let me know if it's working 5.2
or 5.2.z.
Thanks.

OK, I think this is related to a similar problem that dhcp6c had earlier. We weren't saving the generated DUID in dhcp6c, so a call to save_duid() was added.
I've added calls to save_duid() in dhcp6s in the same style as what we did in dhcp6c. This should solve the consistency between reboots problems.
One thing that's confusing to me is that get_duid() will either read in the saved DUID or generate a new one, then it calls save_duid() to save it. However, that is what's happening now and the consistency is not there, so something must occur to the DUID during the course of the program running, so we need to save it again.
If this patch doesn't fix things up, my suggestion will be to modify the signal handler in dhcp6s to call save_duid() before exiting to ensure we have the latest copy saved.
The fix will be in dhcpv6-1.0.10-8.el5.

Fixed this in dhcpv6-1.0.10-10.el5. This one has taken me a while. I retraced everything today and finally figured out what was happening. I had been looking at the wrong place in the code the entire time.
Once we have the client DUID, the server DUID LLT field is updated so they match. The rest of the DUID is left untouched.
Watching the communication via wireshark, it looks like this will work for the test (I hope anyway). Attaching the patch so you can see. It ended up being pretty simple.

I just retested dhcpv6-1.0.10-10.el5 and with dhcpv6-1.0.10-11.el5 and the DUID LLT values match for the client and server. I did an information request and a normal IANA exchange and the LLT time value matched the entire time.
The DUID also remained consistent through reboots.
The MAC field of the DUID is different between the client and server, but that is how it should be, right? The server DUID should have the server MAC address and the client DUID should have the client MAC address, right? The DUID LLT should match between both of them.
Please retest using dhcpv6-1.0.10-11.el5. I am showing the LLT TIME values are matched with both dhcpv6-1.0.10-10.el5 and dhcpv6-1.0.10-11.el5.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
http://rhn.redhat.com/errata/RHBA-2009-0165.html

Note

You need to
log in
before you can comment on or make changes to this bug.