Subject: Re: Reimplementing broadcast check for ARP
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: mark <mds@gbnet.net>
List: tech-net
Date: 10/02/1997 14:33:39
Would this be an Auspex?

It sounds like their ServerGuard feature and I think may be a special
case in that they have very great control over their network interfaces
at all levels and can do practically anything they want with them.

On Thu 2 Oct, 1997, der Mouse  <mouse@Rodents.Montreal.QC.CA> wrote:
> > When building the new ARP system, I left commented out the test that
> > the reported linklevel address is not the broadcast address).
> 
> > Problem was that the new ARP system can't know, per se, what the
> > broadcast address IS.
> 
> This is also assuming that the broadcast cannot be legitimately used in
> an arp reply.  I'm not sure whether I think this is true or not.  BUT:
> 
> > However, even multicast addresses should be inappropriate for ARP
> > entries:
> 
> This is definitely false.  I know of at least one system where it is
> crucial that a client accept a multicast Ether address in a ARP reply.
> (It's a redundant server system, with two or more machines which decide
> among themselves who will answer requests; when one dies, the rest
> decide who will take over - the reason it's transparent to clients is
> precisely that it works by answering arps for the server IP address
> with a multicast Ethernet address, one that all the servers set
> themselves to receive.)
> 
> 					der Mouse
> 
> 			       mouse@rodents.montreal.qc.ca
> 		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B