[rbridge] ARP proxying

[Joe Touch]

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



Guillermo Ibáñez wrote:
> I agree we must look for a different term.
> English is not my mother tongue so I beg your pardon in advance if it 
> sounds bizarre (weird). How about ARP "recording"  or "storing" (just to 
> differentiate). 

These are nuances on the idea of caching - they address capturing and
retaining ARPs seen on the net. The key feature of what is being
proposed is to then replay them as if they came from the original source.

I found a couple of other possibilities, but each isn't as accurate as
replay, IMO:

	- repeater
		typically this indicates the copy of an incoming frame
		is sent on an outgoing link; in our case, we want the
		copy to be generated in response to the ARP request,
		not just to relay the ARP reply

	- relay
		same issue as repeater

IMO, replay is the most accurate for this kind of optimization, with
'spoofing' just as accurate but with a strong hint that the spoofer is
malicious.

PS - it would be useful to see RFC3756 regarding this issue, and RFC3971
which appears to defeat such optimization in an rbridge.

- ----

That said, I agree with Radia if the term "ARP/ND optiimization" is the
general term. I also agree that replying with the destination's MAC is
the right answer; at no point should non-Rbridge nodes on the net ever
know - or need to know - about the MAC of an rbridge device, IMO.

> In the drat Abridges I use ARP "registering", but this 
> is an intentional operation.

That sounds right for what is intended there.

Joe

> Guillermo
> 
> Gray, Eric wrote:
> 
> 
>>Joe,
>>
>>--> > 	The fact that RFC 925 describes using a cache or ARP 
>>--> > entries as a basis for what RFC 1009 subsequently defines as
>>--> > ARP caching (or "the ARP hack"), in no way implies that this 
>>-->
>>--> proxy ARP in 1009. 
>>
>>Yeah, meant to say "proxy ARP" instead of "ARP caching".
>>
>>--> > 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.
>>
>>--> > 	While it is clearly too late to change the prior usage,
>>--> > the function described in RFC 1009 would be better termed an
>>--> > "ARP Translation" than an "ARP Proxy".
>>--> 
>>--> That would require our redefining that term, as well as corresponding
>>--> proxy terms in other widespread use - notably web proxy. 
>>
>>Argument for the sake of argument.  You and I both agree that
>>we shouldn't use "ARP Proxy" or "Proxy ARP" in this context.
>>That was abundantly clear in the remainder of the text, as was
>>also the fact that I am not arguing to change the past.
>>
>>--> Proxying in these cases, as well as in general English, 
>>--> refers to one party _representing_ another, not trying to 
>>--> fake being another.
>>
>>Exactly!  Glad we agree...
>>
>>--> > 	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.
>>
>>Or perhaps it is just me.  Anybody else care to suggest a term?
>>
>>--> -----Original Message-----
>>--> From: rbridge-bounces at postel.org 
>>--> [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
>>--> Sent: Monday, December 19, 2005 11:22 AM
>>--> To: Developing a hybrid router/bridge.
>>--> Subject: Re: [rbridge] ARP proxying
>>--> 
>>--> _______________________________________________
>>--> rbridge mailing list
>>--> rbridge at postel.org
>>--> http://www.postel.org/mailman/listinfo/rbridge
>>--> 
>>_______________________________________________
>>rbridge mailing list
>>rbridge at postel.org
>>http://www.postel.org/mailman/listinfo/rbridge
>>
>> 
>>
> 
> 

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

iD8DBQFDqFwpE5f5cImnZrsRAhhIAJ0SoTf2TX2YFrx8FTSYt9j97B/cYwCeLpaG
lY0fTqVQ3AMYFHRdqPTQLGE=
=7HhS
-----END PGP SIGNATURE-----