Subject: [rbridge] ARP proxying

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 16 Dec 2005 18:43:53 -0500

Radia/Joe,

	We can call it ARP caching (which would make some sense
- possibly more than ARP replay), ARP replay or ARP Proxy.  I
am not sure where Joe's definition of "proxy" comes from, but
- if we assume that definition, then ARP proxy is not what we
have talked about at all.

	However, ARP proxy/caching/replay/<whatever> is really
an optimization - similar to the multicast optimizations of
Sue's draft.  I am reasonably sure that it does not need to
be part of the base-line RBridge specification in order to be
of use (again, much like the multicast optimization).

	Is this in the WG charter?  Should it be?

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Friday, December 16, 2005 4:37 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] ARP proxying
--> 
--> Yes Joe, you are right. This was a confusion over the word. 
--> I have used
--> "ARP proxy" to mean someone replies to the request, whether 
--> it be with
--> the target's actual MAC address, or with one's own MAC 
--> address. So with
--> your definition ("proxy" means you reply with your own MAC 
--> address), 
--> then you
--> are right...we do not want RBridges to do ARP proxy. But we
--> do want them to do ARP replay.
--> 
--> I suspect I'm not the only one who uses "ARP proxy" in the 
--> more general way,
--> so we have to be careful not to confuse people when we say 
--> RBridges will
--> not do it.
--> 
--> But whatever we call things, I'm glad we aren't disagreeing 
--> about how 
--> the thing
--> works functionally.
--> 
--> Radia
--> 
--> 
--> 
--> Joe Touch wrote:
--> 
--> >-----BEGIN PGP SIGNED MESSAGE-----
--> >Hash: SHA1
--> >
--> >
--> >
--> >Radia Perlman wrote:
--> >  
--> >
--> >>I'm changing the subject line to make it easier, as least 
--> for me, to
--> >>find mail on specific issues.
--> >>
--> >>I remember writing up alternatives for ARP/ND proxying and
--> >>sending the choices and pros and cons to the list, and 
--> I'm not sure there
--> >>was ever strong opinions voiced on any of them.
--> >>However, I am quite sure the WG did not rule
--> >>out ARP proxying.
--> >>
--> >>I prefer ARP proxying, rather than treating ARP like any 
--> other L2 traffic.
--> >>We could make things a bit fancier, for instance,
--> >>a) further cutting down on
--> >>traffic by having an RBridge suppress an ARP request to a 
--> particular 
--> >>target if
--> >>it knows that another one has occurred recently (either because it
--> >>iniated it as ingress RBridge or because it forwarded the 
--> encapsulated ARP
--> >>query)
--> >>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.
--> >>
--> >>Joe...you seem to be definitively stating that the WG has 
--> ruled out 
--> >>ARP/ND proxy.
--> >>    
--> >>
--> >
--> >We need to be clear about the difference between ARP Proxy and ARP
--> >Replay. Replay is closer to what we have always been 
--> talking about. We
--> >never talked about proxying.
--> >
--> >For proxying to work:
--> >
--> >	1- a designated rbridge would intercept an ARP
--> > 	and reply with its own MAC address
--> >
--> >	2- the rbridge would need to know to which egress to forward
--> >	the packet
--> >
--> >	3- the egress would need to know the MAC on the destination LAN
--> >
--> >steps 2 and 3 involve a new set of state in the rbridge 
--> campus that we
--> >haven't talked about.
--> >
--> >My impression is thus that we've been talking about replay 
--> more than
--> >proxy. Correct me (anyone) if that's not accurate...
--> >
--> >Joe
--> >
--> >  
--> >
--> >>I may have missed some of the emails on the list (it's 
--> *really* hard
--> >>to keep up with the volume of traffic). Was this debated 
--> and concluded 
--> >>somehow?
--> >>Or were you just misremembering? Ruling proxy out is 
--> definitely a change 
--> >>from
--> >>the original intent, and changes such as this should not be done 
--> >>arbitrarily.
--> >>
--> >>Radia
--> >>
--> >>
--> >>
--> >>
--> >>Guillermo Ib??ez wrote:
--> >>
--> >>
--> >>    
--> >>
--> >>>ARP Proxying by the Designated Rbridge was considered an 
--> acceptable 
--> >>>optimization,  right?
--> >>>GI
--> >>>Joe Touch wrote:
--> >>>
--> >>>
--> >>>
--> >>>
--> >>>      
--> >>>
--> >>>>Guillermo Ib??ez wrote:
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>>My understanding was that Rbridges would do ARP 
--> proxying and would 
--> >>>>>>forward ARP requests to other Rbridges. Am I still right?.
--> >>>>>>   
--> >>>>>>
--> >>>>>>      
--> >>>>>>
--> >>>>>>            
--> >>>>>>
--> >>>>Not proxying; they forward ARPs like all other L2 
--> traffic. They don't
--> >>>>generate ARPs directed at their own L2 addresses in 
--> response to seeing
--> >>>>other ARPs (proxying).
--> >>>>
--> >>>>Joe
--> >>>>
--> >>>>
--> >>>>
--> >>>>--------------------------------------------------------
--> ----------------
--> >>>>
--> >>>>_______________________________________________
--> >>>>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
--> >
--> >iD8DBQFDoy3iE5f5cImnZrsRAt5qAKC9NMQuOkDFJuBg5uT8PQQBywFmhgCdEA2v
--> >IQMHjRlNxrTNAsFDK7jRkrc=
--> >=3qHZ
--> >-----END PGP SIGNATURE-----
--> >_______________________________________________
--> >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
-->

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 16 Dec 2005 16:52:41 -0800

Gray, Eric wrote:
> - possibly more than ARP replay), 

ARP caching is what hosts and proxy ARP-ing routers already do (ala
RFC1122).
See TCP/IP Illustrated, Vol 1, section 4.3.

> ARP replay or ARP Proxy.  I

FWIW, proxy ARP is in RFC1009, as referred to by RFC1122.
See TCP/IP Illustrated, Vol 1, section 4.6, which describes it in detail
as I have, and equates it to "promiscuous ARP" and the "ARP hack".

> 	Is this in the WG charter?  Should it be?

Optimizations don't need to be in the charter, IMO.

Joe

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

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 16 Dec 2005 20:29:11 -0800

I believe the ARP/ND optimization does need to be in the draft, because the
solutions we've talked about need to be done by all RBridges.

Radia