[FS#309] Can't assign static IPv6 leases anymore

[LEDE Bugs]

A new Flyspray task has been opened.  Details are below. 

User who did this - arjendekorte (arjendekorte) 

Attached to Project - LEDE Project
Summary - Can't assign static IPv6 leases anymore
Task Type - Bug Report
Category - Packages
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - Low
Priority - Very Low
Reported Version - Trunk
Due in Version - Undecided
Due Date - Undecided
Details - Commit 41164ba2dc2365f95f27db8b36e60b3c92db01a8 broke the configuration of static DHCPv6 leases.

In /etc/config/dhcp, I have the following entry

config host
        option name 'orthros'
        option mac '80:86:f2:26:f3:8b'
        option ip '192.168.1.100'
        option duid '0004966a3942290f138f95aa81633bcd4237'
        option hostid '100'

Previously, the connecting device with this DUID received the address '2001:db8:beef:100' with the following entries in /tmp/hosts/odhcpd:

# wlan0-2 0004966a3942290f138f95aa81633bcd4237 0 orthros 0 100 128
2001:db8:beef::100      orthros.example.com     orthros
# br-lan 0004966a3942290f138f95aa81633bcd4237 f226f38b orthros 1480170104 100 128 2001:db8:beef::100/128

Since this patch, it will receive a different address '2001:db8:beef::35a' and the following is in /tmp/hosts/odhcpd:

2001:db8:dead::100      orthros.example.com     orthros
# wlan0-2 0004966a3942290f138f95aa81633bcd4237 0 orthros 2147483647 100 128 2001:db8:dead::100/128
2001:db8:beef::100      orthros.example.com     orthros
# br-lan 0004966a3942290f138f95aa81633bcd4237 0 orthros 2147483647 100 128 2001:db8:beef::100/128
2001:db8:beef::35a      orthros.example.com     orthros
# br-lan 0004966a3942290f138f95aa81633bcd4237 f226f38b orthros 1480171596 35a 128 2001:db8:beef::35a/128

Despite the matching DUID, the client gets a different address. Also note the additional entries for '2001:db8:dead::100'. These are not active, so it is a bit confusing they show up in the state file.

I also have my doubts about using 2147483647 as 'infinite'. While 2038 is more than two decades away, I'm old enough to remember the trouble of Y2K incompatibility. This field should really be treated as an UINT32 so that rollover issues won't happen before 2106 (which would be well beyond my life expectancy).

More information can be found at the following URL:
https://bugs.lede-project.org/index.php?do=details&task_id=309