[rbridge] An ARP/ND draft
mjkantowski at yahoo.com
Fri Jul 16 17:01:34 PDT 2010
I agree with Joe's final statement about stateless handling of ARP. After all,
neither bridges nor routers do this sort of advanced ARP handling, so why should
rbridges take this on. Isn't the amount of steady state broadcast traffic
something that we worried about on hubs?
Unless we are concerned that TRILL will lead to the creation of humongous
broadcast domains, perhaps ARP optimization/handling should be toned down to the
----- Original Message ----
From: Joe Touch <touch at ISI.EDU>
To: Donald Eastlake <d3e3e3 at gmail.com>
Cc: rbridge at postel.org
Sent: Fri, July 16, 2010 6:24:30 PM
Subject: Re: [rbridge] An ARP/ND draft
I agree with Linda that this is just describing an existing mechanism to
respond with a cached ARP reply (not proxy ARP, though - see below).
IMO, that means this doc could boil down to a few simple sentences,
i.e., that the rbridge ingress can perform cached ARP reply. What else
is there to really add?
NB: proxy ARP is when you respond NOT with the intended destination MAC,
but with *your own*, i.e., it is intended for cases where you will act
as a relay for subsequent traffic.
On other points:
I think this doc warrants a specific security considerations section. In
particular, it can amplify the effects of ARP poisoning, as it presents
another place where proxy ARPs could continue to respond with incorrect
Further, the third alternative (forward the ARP to the known egress
rbridge) defeats visibility of such requests by the legitimate receiver
if on another egress, which defeats its ability to respond with a
potentially colliding (and thus informative) response.
This seems worth noting, IMO.
As others have noted, I don't see the utility in variant 3 (forward the
ARP to the known egress). Either the ingress knows the ARP response and
can proxy it, or it does not, in which case why would it know the egress
merely from the L2 info? I don't see why an rbridge would cache the
egress:IP correlation and not simply cache the proxy ARP response.
What's the benefit to this alternative?
As others have noted, rbridges should not repeatedly flood ARPs. That's
the source's job. I don't see utility - or safety - in assuming that
ingress rbridges throttle or otherwise affect ARP traffic. IMO, they
either proxy it or leave it alone (and broadcast it). Whatever it does,
it should do for every ARP it sees independently, statelessly.
On 7/6/2010 8:25 PM, Donald Eastlake wrote:
> An early ARP/ND draft is available at
> It is primarily based on material that was in the -03 and earlier
> versions of the TRILL base protocol draft. It was not submitted in
> time to get into the Internet Draft directories before the upcoming
> IETF meeting.
> Donald E. Eastlake 3rd +1-508-333-2270 (cell)
> 155 Beaver Street
> Milford, MA 01757 USA
> d3e3e3 at gmail.com
> rbridge mailing list
> rbridge at postel.org
rbridge mailing list
rbridge at postel.org
More information about the rbridge