Subject: [rbridge] ARP proxying

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 19 Dec 2005 13:14:17 -0500

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
-->

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 19 Dec 2005 14:49:46 -0800

Gray, Eric wrote:
...
> 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.

...
> term was not genuine as you appear unwilling to accept any such

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 19 Dec 2005 14:51:59 -0800

> the latter ends up being called), it's clear it isn't appropriate to
           ^^

to describe what it is that rbridges should/could do for optimization...

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Tue, 20 Dec 2005 18:48:04 +0100

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). In the drat Abridges I use ARP "registering", but this 
is an intentional operation.
Guillermo

Gray, Eric wrote:

>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

-- 
Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid
1.1.B.11 Colmenarejo 91-6241393
4.1.F.13 Legan?s 91-6248794

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 20 Dec 2005 10:51:33 -0800

How about just "ARP/ND optimization". That means that we don't have to 
give a name
to the actual mechanism...I think that term would be clearly implying 
that there are various
mechanisms that could do this. I'd hate to have to change the word if we 
decided that
the Designated RBridge on the querier's link should respond with any of 
the following:

a) the target's MAC
b) the DB's MAC
c) the egress RBridge's MAC
d) a logical MAC address meaning "my DB's MAC".

I considered all of these possibilities, and discussed it with a few 
people. We concluded
that target's MAC was most logical, though any of the above would work. 
I was using
the term "ARP/ND proxy" all along and it didn't seem to confuse anyone, 
but I don't
care about the words...just how the thing works.

There were other alternatives discussed, including not optimizing 
ARP/ND...just forwarding
them like any other L2 multicast, as well as sending directly to the 
assumed DB of the target,
and forcing the actual target to respond. I think, as I said, that 
perhaps one of these
alternatives should be done sometimes, in case the cache is stale. In 
DECnet we had
a "tryhard" bit that was used primarily in the interface from layer 4 to 
layer 3 inside a node,
which said "get rid of caches that might be stale", which was invoked if 
layer 4 was having
a hard time making a connection to a target. It might be nice to add 
such signalling
from endnode to RBridge at some point, but we don't need it now.

If people care, even though I suspect it's alread in the email archives 
somewhere, I can explain
why responding with the target's MAC seemed the best of the alternatives.

Radia

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 20 Dec 2005 11:31:53 -0800

Guillermo Ib??ez wrote:
> 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 

That sounds right for what is intended there.

Joe

---

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Tue, 20 Dec 2005 20:54:06 +0100

--On tirsdag, desember 20, 2005 10:51:33 -0800 Radia Perlman 

> that target's MAC was most logical, though any of the above would work.

"ARP/ND optimization" is a fine name.
I don't think either of b), c) or d) would work (for some definition of 
"work") - if you instantiated any of them, the RBridges would have to 
inspect every single packet with such a destination MAC, verify that the 
content was an IP packet, and forwarding based on the L3 address.

I don't think that's a bridge any more.

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 20 Dec 2005 13:31:23 -0800

> the Designated RBridge on the querier's link should respond with any of 

That corresponds to what I was calling "ARP replay"

> b) the DB's MAC

That corresponds to proxy ARP, and works only if the DB then translates
that to the MAC of the destination for every frame.

> c) the egress RBridge's MAC

That doesn't appear to work; the node sending the ARP request would then
send unencapsulated traffic to the egress, defeating the 'routing'
inside the rbridge campus.

> d) a logical MAC address meaning "my DB's MAC".

I'm not sure how this differs from (b), except to use a logical MAC
rather than the physical MAC. The effect would be the same.

Of the above, only (a) will continue to work if the rbridges are swapped
with bridges, e.g., for maintenance or due to device failure.

> ARP/ND...just forwarding them like any other L2 multicast, as well as
> sending directly to the assumed DB of the target, and forcing the
> actual target to respond. I think, as I said, that perhaps one of
> these alternatives should be done sometimes, in case the cache is
> stale. In DECnet we had a "tryhard" bit that was used primarily in
> the interface from layer 4 to layer 3 inside a node, which said "get
> rid of caches that might be stale", which was invoked if layer 4 was
> having a hard time making a connection to a target. It might be nice
> to add such signalling from endnode to RBridge at some point, but we
> don't need it now.

Stale caches are only one issue; how the caches are refreshed is
another. Typical ARP caches are refreshed when _either_ they are
referenced locally or when a new ARP reply is seen (source address of
the entry in question, see RFC1122 sec 2.3.2.1). It would be hard to
flush entries in a cache that are nonlocal - as per that section. I.e.,
if the cache is moved from the host, it needs to have the signalling
described above at a minimum.

The other issue is the 'silent relocation' - when a node's MAC address
changes, or when it silently moves from the segment of one DR to
another. In either case, traffic will be misdirected until the receiver
speaks up, but there would be no reason for the receiver to do so.

As a result, it would be useful to consider the advice of RFC1122 (same
section) on proxy ARP - to limit the rbridge caching of replies to 1
minute max, regardless of refresh.

Joe

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 20 Dec 2005 14:02:46 -0800

I wasn't arguing about changing the mechanism (that the first RBridge 
responds to an
ARP/ND query with the target's MAC address). I was just saying that I 
don't want the
name to change if we make slight changes to how it works. So the only 
thing I was
arguing was to use the term "ARP/ND optimization" rather than "replay" 
"proxy" or
whatever, which seem to have specific and different meanings to people.

I always think it's useful to consider all sorts of variants of a 
scheme, and to think about their
pluses and minuses. I wasn't advocating answering anything other than 
with the target's MAC address,
because after carefully considering the implications of the 
alternatives, we concluded answering
with the target's MAC address was the best choice.

So the only point of my note is that we come up with a generic name for 
the mechanism, or the
problem we are solving, and then in the spec we say exactly how it 
works, rather than choosing
a name that we think will define the mechanism just by its name.

So...we're all agreeing, right? We'll call it "ARP/ND optimization", the 
main mechanism will be
that an RBridge responds to an ARP/ND query with the target's MAC 
address (if known),
and we might also suggest states when something more drastic is done 
rather than depending on
the RBridge's cache being correct.

Radia

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Radia Perlman wrote:
>  
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDqHgrE5f5cImnZrsRAhAVAJ0Rd6WqA5m1kRvUcqxjrhZfjirLdACfRxEk
>hE4Zdhs0Ij3mQQVUc+m71uE=
>=yOXx
>-----END PGP SIGNATURE-----

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 20 Dec 2005 14:08:41 -0800

Agreed.

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Wed, 21 Dec 2005 11:57:01 +0100

I agree with Radia term "ARP optimization" where no specificity is 
desired or required, and with Joe's term "ARP replay" when an accurate 
description is needed.
Guillermo

Joe Touch wrote:

>iD8DBQFDqFwpE5f5cImnZrsRAhhIAJ0SoTf2TX2YFrx8FTSYt9j97B/cYwCeLpaG
>lY0fTqVQ3AMYFHRdqPTQLGE=
>=7HhS