Bug #22675 for dhcp-public: [patch] dhclient -6 honors already-expired leases

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.

---