Der Mouse wrote:

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

The RFC mandates this check. I only commented that code out from the original
code because I hadn't decided yet how to implement it.

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

Thats "poor mans ANYCASTing". Fortunately, IPv6 will give us real anycasting,
and we won't need that hack anymore.

Well, the RFC doesn't tell anything about that. I assumed this might be a 
result of its age, and general multicasting being pretty young.

I'm still convinced it _should_ be forbidden, because of the DOS potential,
but I accept your argument as describing the status quo.

I'll try an ==A== test implementation (==B== already works on 2 test
machines).

Regards,
	Ignatios