On Jun 29, 2017, at 1:29 PM, Thomas Markwalder via RT wrote: > I have reproduced the issue and it is not related to the size of your configuration but then I didn't really think it would be. The problem is that the client classification of a packet is done BEFORE the global statements are executed for that packet. This means the classification is actually being done based on the binding variables set by previous packet. > > You can see this in the logs. A SOLICIT from a bad client matches because the previous packet was from a good client. The ensuing REQUEST from the bad client does not match because the variables are now based on the bad client's SOLICIT. Well, it all makes perfect sense now. Glad it's not a bug. > The reason this is not an issue for your V4 configuration is because your match argument is "hardware" and that value is available directly from the packet when classification is done. > > The "match" clause can support expressions such as match pick_first_value(...) or match suffix(option dhcp6.client-id,6) and so forth. Those are calculated as part of the classification evaluation. You should be able to come up with expressions that will meet your needs but you would have to repeat them for each class declaration. Not as clean as what you wanted to do but the software currently won't support that. I'll give that a go. > I'll continue to explore this and will keep you updated. Thanks. Also, consider the following: In 2009 David W. Haskins wrote, with respect to DHCPv6 and hardware addresses(*): > I'm inclined to make 'hardware ethernet ...;' just work, assuming > the client is sending either of those two types of DUID, ... Clearly that's happened. If ISC would extend that to "match hardware", all my dhcpd.conf futzing to tease the hardware address out of the clientid would be unnecessary. (And, I suspect, there would be much rejoicing.) Thank you very much for the quick turnaround and detailed explanation. -- Rob Riepel (*) https://lists.isc.org/pipermail/dhcp-users/2009-February/008463.html