[rbridge] An ARP/ND draft

[Michael Kantowski]

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 
bare essentials.

-mike



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

Hi, Donald,

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

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.

Joe

On 7/6/2010 8:25 PM, Donald Eastlake wrote:
> An early ARP/ND draft is available at
> http://pothole.com./~dee3/drafts/draft-eastlake-trill-rbridge-arp-xx.txt
>
> 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.
>
> Thanks,
> Donald
> =============================
>   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
> http://mailman.postel.org/mailman/listinfo/rbridge
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge