Hello,

I'm sending a patch for dhcpv6 client.
With this patch dhclient checks whether there is
any unexpired address in previous lease
prior to confirming (INIT-REBOOT) the lease.

For the initial reason see this bug report
https://bugzilla.redhat.com/show_bug.cgi?id=585418

Here is my additional investigation and suggestion:

DHCPv4 client first looks whether the active lease is expired.
If it's not, he starts to send DHCPREQUEST.
If it is, he goes to INIT state, i.e. starts to send DHCPDISCOVER.
If he get's no response in INIT state he
runs (panic_state()) through the list of leases and see if one can be used.

DHCPv6 client on the begining looks if there's any previous binding
and without checking whether it isn't  already expired he directly goes
to CONFIRM state. If he gets no response he bounds the old lease
without checking whether it isn't already expired.

I know that Section 18.1.2. (Creation and Transmission of Confirm Messages)
of RFC 3315 says:
    *   If the client receives no responses before the message
    *   transmission process terminates, as described in section 14,
    *   the client SHOULD continue to use any IP addresses, using the
    *   last known lifetimes for those addresses, and SHOULD continue
    *   to use any other previously obtained configuration parameters.

But I think 'dhclient -6' can avoid some work
if it was working the same way as 'dhclient -4',
i.e. by checking whether the lease is not already expired before 
confirming/binding it.
I know ISC dhcp is reference implementation
so my patch will probably be refused.

Just look at
https://bugzilla.redhat.com/show_bug.cgi?id=585418
and think about it :-)

Thank you.

Jiri Popelka
Red Hat, inc.