This line of thinking is not entirely without precedent or relevance.
About 16 or 17 years ago I spent some time looking at ARP behavior quite closely, and learned a lot about it. Few people know, for instance, that you can often reliably use ARP to perform covert broad-brush OS fingerprinting at layer 2, based upon the delay time(s) observed between unanswered ARP requests induced from the target system for a non-existant segment-local system, which in turn can be achieved by sending a single spoofed frame or packet. Ugly original perl over here: http://packetstormsecurity.com/files/21904/induce-arp.tgz.ht...
Anyway, point of story was since then I've taken a bit of an interest in what little ARP-related stories have popped up. There has for a long time what I assume to be a fairly mature, persistent, userspace ARP cache management daemon in Linux, arpd with docs @ http://linux.die.net/man/8/arpd .. so userspace management is not without precedent. In that case its purpose is "avoid redundant broadcasting due to limited size of kernel ARP cache". Since the cost of broadcasting ARP is almost zero in 99.99% of ethernet-like cases, this is probably only for special link layers.
However, if we look critically at the present, with the rise of automated infrastructure (things like 'Software Defined Networking') the potential for sharing the results of local segment changes across disparate devices in an out of band fashion for the purpose of locking down layer two filtering on physical and virtual (VLAN, etc.) interfaces is not without value.
About 16 or 17 years ago I spent some time looking at ARP behavior quite closely, and learned a lot about it. Few people know, for instance, that you can often reliably use ARP to perform covert broad-brush OS fingerprinting at layer 2, based upon the delay time(s) observed between unanswered ARP requests induced from the target system for a non-existant segment-local system, which in turn can be achieved by sending a single spoofed frame or packet. Ugly original perl over here: http://packetstormsecurity.com/files/21904/induce-arp.tgz.ht...
Anyway, point of story was since then I've taken a bit of an interest in what little ARP-related stories have popped up. There has for a long time what I assume to be a fairly mature, persistent, userspace ARP cache management daemon in Linux, arpd with docs @ http://linux.die.net/man/8/arpd .. so userspace management is not without precedent. In that case its purpose is "avoid redundant broadcasting due to limited size of kernel ARP cache". Since the cost of broadcasting ARP is almost zero in 99.99% of ethernet-like cases, this is probably only for special link layers.
However, if we look critically at the present, with the rise of automated infrastructure (things like 'Software Defined Networking') the potential for sharing the results of local segment changes across disparate devices in an out of band fashion for the purpose of locking down layer two filtering on physical and virtual (VLAN, etc.) interfaces is not without value.