| Date: | Thu, 22 Jun 2017 18:18:34 -0700 |
| From: | "Rob Riepel" <riepel@stanford.edu> |
| Subject: | [confidential] DHCPv6 client class matching bug in DHCP server 4.3.5 |
| To: | dhcp-bugs@isc.org |
[confidential] to keep the detail of our config out of the public view per our management.
We currently use DHCPv4 client classes to great avail. Our v4 setup looks something like this:
class "roaming" { match hardware; }
class "frozen" { match hardware; }
class "vile" { match hardware; deny booting; }
shared-network AiF-net.stanford.edu {
subnet 10.86.67.192 netmask 255.255.255.192 {
option routers 10.86.67.193;
pool {
allow members of "frozen";
max-lease-time 2520; default-lease-time 2520;
range 10.86.67.212 10.86.67.231;
}
}
subnet 171.66.67.192 netmask 255.255.255.192 {
option routers 171.66.67.193;
pool {
allow members of "roaming";
max-lease-time 2520; default-lease-time 2520;
range 171.66.67.222 171.66.67.251;
}
}
}
host sr16-1bba467e4a-fcfc48d6e6ea { ethernet fc:fc:48:d6:e6:ea; }
subclass "roaming" 1:fc:fc:48:d6:e6:ea;
host daedalus-c82a14291f57 { hardware ethernet c8:2a:14:29:1f:57; fixed-address 171.64.20.40; }
subclass "vile" 1:c8:2a:14:29:1f:57;
We've duplicated that for DHCPv6, by teasing the LL address out of DUIDs that include it, so we can use the same DHCP configuration generation tools. The v6 configs looks like:
class "roaming" { match su-client-id; log(debug, "roaming match"); }
class "frozen" { match su-client-id; log(debug, "frozen match"); }
class "vile" { match su-client-id; log(debug, "vile match"); deny booting; }
# where, su-client-id == 1:LLaddress (details in attached bug report)
shared-network Pine-B-net.stanford.edu {
subnet6 2607:f6d0:0:a13f::/64 {
pool6 {
allow members of "roaming";
max-lease-time 2520; default-lease-time 2520;
range6 2607:f6d0:0:a13f:bad:c0ff:ee:1 2607:f6d0:0:a13f:bad:c0ff:ee:6e;
}
}
}
host Scar-f44d30426ad3 { hardware ethernet f4:4d:30:42:6a:d3; }
subclass "roaming" 1:f4:4d:30:42:6a:d3;
host daedalus-109add9e9ea5 { hardware ethernet 10:9a:dd:9e:9e:a5; }
subclass "vile" 1:10:9a:dd:9e:9e:a5;
In testing to make sure "vile" hosts never obtain leases, we found they did. Repeated tests confirmed this and suggest an indexing problem in the dhcpd class matching algorithm. I believe the attached bug report (appended as an attachment to avoid mail mangling) shows this, as clients show up in the class of the previous client.
The attached report includes version information, the relevant bits of the dhcpd.conf, and an annotated section of the log file starting from dhcpd start until after the problems (no log lines have been excluded). I would attached the full dhcpd.conf, but it's quite large (18M). Let me know if you want it.
Happy to test patches if it comes to that.
--
Rob Riepel
Message body is not shown because sender requested not to inline it.