Subject: Re: Reimplementing broadcast check for ARP
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Ignatios Souvatzis <email@example.com>
Date: 10/02/1997 16:41:37
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.
> > 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