illumos gate

Henner Gratz wrote:

If there is a CLIENT_ID (RFC 3315 DUID of type 1 or 3) defined in /etc/default/dhcpagent, /sbin/dhcpagent isn't able to parse it beacuse of a few bugs in its parser. This makes it quite difficult to assign a fixed IPv6 address to a DHCPv6 client. The bugs are in function get_smach_cid() in the file /usr/src/cmd/cmd-inet/sbin/dhcpagent/states.c. I've attached a patch file that (hopefully) corrects the bugs. (Perhaps a range check for the time-value of DUID-LLT's would be good.)

The time value in the type 1 DUID was NOT intended to be specified by the user. It shouldn't be. The DUID (once generated) is stored in stable storage and reused. I disagree with that part of this change, and have not inspected the rest.

I'll leave it to a maintainer to look at the rest.

According to the comment at the beginning of the function Look in defaults file for the client-id. If present, this takes precedence over all other forms of ID. That means the ID in /etc/default/dhcpagent replaces the once generated stable ID saved to /etc/dhcp/duid. And so it should be stable across reboots too.

A CLIENT-ID entry added to /etc/default/dhcpagent is there to make sure that a machine uses a certain DUID for identification. It doesn't make sense to let the client create a new DUID-LLT with every reboot by replacing the timestamp part with the current time. All DHCPv6 servers using the DUID for recognizing the client can't do so because of the changing timestamp.