[127224] in North American Network Operators' Group
Re: Sending ARP request to unicast MAC instead of broadcast
daemon@ATHENA.MIT.EDU (Crist Clark)
Thu Jun 17 16:56:34 2010
Date: Thu, 17 Jun 2010 10:57:46 -0700
From: "Crist Clark" <Crist.Clark@globalstar.com>
To: <nanog@nanog.org>,"Chris Woodfield" <rekoil@semihuman.com>
In-Reply-To: <7D4FBC01-E09F-4659-B620-310DCB11C20A@semihuman.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
>>> On 6/16/2010 at 3:57 PM, Chris Woodfield <rekoil@semihuman.com> =
wrote:
> OK, this sounds Really Wacky (or, Really Hacky if you're into puns) =
but=20
> there's a reason for it, I swear...
>=20
> Will typical OSS UNIX kernels (Linux, BSD, MacOS X, etc) reply to a =
crafted=20
> ARP request that, instead of having FF:FF:FF:FF:FF:FF as its destination =
MAC=20
> address, is instead sent to the already-known unicast MAC address of the =
host?=20
>=20
>=20
> Next, what would be your utility of choice for crafting such a packet? =
Or is=20
> this something one would need to code up by hand in a lower-level =
language?
Unicast ARP requests are considered normal. See Section 2.3.2.1 of
RFC1122, "ARP Cache Validation." Specifically,
IMPLEMENTATION:
Four mechanisms have been used, sometimes in
combination, to flush out-of-date cache entries.
[snip]
(2) Unicast Poll -- Actively poll the remote host by
periodically sending a point-to-point ARP Request
to it, and delete the entry if no ARP Reply is
received from N successive polls. Again, the
timeout should be on the order of a minute, and
typically N is 2.
