(replying to ietf@)
On Wed, Nov 26, 2008 at 09:38:02AM -0800, Bernard Aboba wrote:
> One such issue is how to rapidly seed the learning tables
> and ARP caches on movement between attachment points.
ARP cache updates shouldn't be necessary when changing attachment
points unless the client's MAC address has changed.
If you change both, then you need to update both. I think they are
separate issues; but in ARP's case it is somewhat unfortunate...you
have to update all ARP caches that may contain an entry for you, for
although you are immediately interested in updating the caches of
those devices with which you are actively communicating, you may
start communicating with other devices at any time (they may initiate
or resume an exchange), and a stale cache entry from an erstwhile
exchange would mean an unfortunate delay.
Additionally, some deployments (passively or actively) attempt to
suppress IPv4 spoofing in BCP-38 similar ways, at the switching
layer, often by intercepting or participating with DHCPv4. In which
case a gratuitous ARP or a DNAv4-like ARP would fail (and in DNAv4's
case it would fall back to INIT behaviour, as I recall, optimizing
for the case where the client has changed networks).
So possibly all three should be considered as sets (a gratuitous
multicast updates learning tables, a broadcast gratuitous ARP updates
ARP caches and learning tables, DHCPv4 updates ACL's, learning tables,
but not ARP caches).
And then of course there's SIP, but let's move on.
> learning tables in advance of station attachment. In DNAv4 (RFC 4436),
> unicast ARP-Requests are sent in order to seed the router ARP cache,
> providing for return reachability within a single exchange. The
> motivation behind both of these devices is to minimize handoff
> latency and frame loss.
I think that DNAv4's primary purpose was to provide a very good
indication that the client had not moved to a different network ("the
same IP-addressed, same MAC-addressed router is probably on the same
broadcast domain as I used to be"). Having determined this, the
client excercises its right not to restart DHCPv4 in order to reassert
its configuration for the network (a lease is good for as long as its
lease-time option says).
The main upshots are that ARP completes much faster for the client,
and in comparison to doing a DHCPv4 INIT-REBOOT; ARP does not require
any 'update to persistent storage' (so it is _far_ less costly).
Any ARP cache update is secondary, and only serves to reinforce
contact between the DNAv4'ing client and the default router(s). It
does not assist with conversations between the client and its peers.
In fact, DNAv4 is likely to suceed in situations where the client has
not changed MAC addresses, but rather has merely been "intermittently
offline", such as when losing and re-associating with an AP, having
its ethernet link toggled, or resuming from a powersave mode (in which
case you will be re-associating with an AP or having your ethernet
link toggled anyway, modulo 'wake-on-lan' features).
In these cases, it is actually pretty unlikely that the router's ARP
cache is incorrect for the selected client. If the client was offline
for an extended period (such as in powersaving), then the router may
have no cache entry for the client, but it should not have an
incorrect ARP cache entry in this case.
--
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/
--
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
Attachment:
pgpFQKJrfyzOK.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf