[rbridge] ARP proxying

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Gray, Eric wrote:
...
> --> > is what anyone would generally refer to as ARP caching.  In
> --> > fact, one use for the cache defined in RFC 925 is the MAC DA
> --> > "translation" that occurs in traversing an Internet Gateway
> --> > (router).
> --> 
> --> Except that the rules for ARP caching are the same for all ARP caches -
> --> regarding cache refresh, timeout, etc. That's why it's useful and
> --> important to consider them equivalent.
> 
> Earlier (Friday, 12/16), in a post on this same subject, Radia said
> (in part) 
> 
>>>b) getting rid of stale ARP caches faster by sometimes (we'd have 
>>>to decide >>under what circumstances) sending the ARP query directly
>>>to the assumed target's link, and making the target respond.
> 
> I am unclear how this behavior is a significant departure from a
> typical ARP cache implementation in a host or router.

ARP caches don't typically remove non-stale entries of their own accord;
when they do, they don't emit ARP requests except based on a trigger of
need (e.g., a cache miss of an IP packet to be emitted).

ARP caches are typically updated by ARP activity as snooped on the wire,
i.e., if a new ARP request or response would replace an entry, the entry
is silently updated.

...
> --> > 	I think many of us are convinced that "ARP Proxy" can't
> --> > be used because of earlier (historical) reasons (whether we
> --> > regard those as in error or not).  I do not think the term
> --> > "ARP Replay" is sufficiently descriptive and I believe that
> --> > the suggestion is made pejoratively - in what certainly looks
> --> > like an attempt to prejudice the working group against any
> --> > such discussion.
> --> 
> --> This _is_ a replay, with all the good AND bad associations. It's
> --> useful to consider those issues, e.g., that replay won't work if
> --> proper anti-replay measures are implemented.
> 
> I disagree.  Apparently, your offer for someone else to suggest a
> term was not genuine as you appear unwilling to accept any such
> suggestion.

Your suggestion was to use ARP caching. We agree not to try to redefine
proxy ARP, but ARP caching has an equally old and established
definition. While it is part of proxy ARP and ARP replay (or whatever
the latter ends up being called), it's clear it isn't appropriate to
describe it either.

It would also be useful to explain how you disagree with my assessment
of how this IS replay (i.e., did you mean it is NOT replay, it is NOT
useful to consider the issues, or that what we're asking an rbridge to
do would continue to work in the presence of anti-replay?)

JOe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDpzkKE5f5cImnZrsRAsJiAJwMja0uTyMUEVZdzqLIHAYck6vJtACg+o2Z
ZVxnIbPbIOUMkT5wwqpf+vo=
=xszf
-----END PGP SIGNATURE-----