pfSense

We are running dhcpd-4.2.1-P1 which supports grouping. The problem is 'host' cannot be related with 'subnet' (I tried different ways to group without success, moreover in some crazy configs dhcpd when started was explicitly saying that 'host' is global: "WARNING: Host declarations are global. They are not limited to the scope you declared them in."
There is a hack that can be relatively easy to implement.
We can specify 'wrong' IPs for interfaces where we do not want this MAC to appear doing something like this:
fixed-address 192.168.56.99,192.168.57.0;
If this host connects to interface 192.168.56.0/24 then it works normally but if user moves this host to 192.168.57.0/24 segment then the host gets 192.168.57.0 and can't do anything.
Let me know if this solution is acceptable and I can implement this.

@Evgeny:
Uuh, nice hack. Accepted! But I don't think it's really easy to implement. Every time, someone creates/modifies/deletes a subnet and enables/disables the corresponding dhcp server you have to check/modify all host entries in dhcpd.conf reflecting the new subnet/dhcp situation. And yes, reading the man pages for dhcpd.conf, host entries do have always a global scope regardless where they are defined.
See also http://www.daemon-systems.org/man/dhcpd.conf.5.html
Thanks for the answer, will hear from you.

That hack might work for the first client to connect in a subnet, but if two of them crossed at once it would not assign the same IP to them both, it would give the second client a valid IP since the first one would be in use in the leases database. At least in theory anyhow.

Just tested with
host s_lan_0 {
hardware ethernet 08:00:27:e5:68:94;
fixed-address 192.168.56.99,192.168.57.0;
}
host s_lan_1 {
hardware ethernet 08:00:27:a6:50:bf;
fixed-address 192.168.56.98,192.168.57.0;

both hosts got 192.168.57.0 on the192.168.57.0/24 interface.
IPs from fixed-address do not appear in leases database, I think this is why the same IP can be given many times.

It still does its ping test to ensure an IP is open before assignment, though I suppose on .0 in a /24 that would fail and it would assign it anyhow.

This is what it does:
01:18:15.819317 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:00:27:a6:50:bf, length 300
01:18:15.819777 IP 192.168.57.254.67 > 192.168.57.0.68: BOOTP/DHCP, Reply, length 300
01:18:15.825990 ARP, Request who-has 192.168.57.0 tell 192.168.57.0, length 46

Yeah that may be fine then, though the code to implement this should not use .0, but mathematically calculate the null route for the subnet on the interface. I believe the function gen_subnet() or similar does just that.

Either way I wouldn't put changes like this into 2.0, but if we can keep a patch handy or in a git fork it could be applied once 2.0 is branched.

Segregation by class (assumed to be directly linked to interface) is now possible.

https://github.com/pfsense/pfsense/pull/4066.

Issue is similar to #4584 (https://redmine.pfsense.org/issues/4584).