

What a distributed, version-controlled ARP cache gets you - mrry
http://www.somerandomidiot.com/blog/2015/04/24/what-a-distributed-version-controlled-ARP-cache-gets-you/

======
contingencies
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...](http://packetstormsecurity.com/files/21904/induce-arp.tgz.html)

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](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.

------
a-lex
no.

~~~
0xdeadbeefbabe
What you aren't in favor of learning experiences?

