[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bugtraq
Subject:    Re: NetBSD Security Advisory 1999-010
From:       Mike Oliver <mike.oliver () eng ! sun ! com>
Date:       1999-05-25 19:25:45
[Download RAW message or body]

Russell Street <russells@AUCKLAND.AC.NZ> wrote:
> I recently researched this and could find any reference in the RFCs or
> common TCP/IP books on using multicast addresses in ARP replies.  The
> ARP RFC (RFC826) does not say one way or the other.

RFC 1812, the "Router Requirements" RFC, says in section 3.3.2:

   A router MUST not believe any ARP reply that claims that the Link
   Layer address of another host or router is a broadcast or multicast
   address.

That RFC was published in June 1995.  A lot of implementations
before that time were happy to accept multicast MAC addresses.
I know this because ...

> > My personal opinion is that ARP should be fixed on all IP stacks
> > (well.. ARP "stack") so that they won't accept multicasts
> > addresses.. I can't think of any reason why they should.
>
> One thing that can be configured to use multicast Ethernet addresses
> for unicast IP addresses is Microsoft's WLBS (Windows Load Balancing
> Server/Service).

 ... in a prior life (ie before I came to Sun) we used an
IP-to-multicast-MAC mapping in a server cluster project, not for load
balancing but for failover.  At any given time only one of the cluster
nodes would have an active IP address above the multicast MAC address,
but if that node failed then some other node would activate the IP
address over the same MAC multicast address.  Voila, IP failover with
no need to worry about refreshing anyone's ARP cache.

At the time (1993?) this worked against all major router vendors except
for, I think, Bay Networks' gear.  However, it always felt like a
kludge and eventually we eventually dropped it in favour of a scheme
that sent unsolicited broadcast ARP responses advertising a unicast MAC
address when this kind of failover occurred.

Mike.
--
mike.oliver@eng.sun.com

[prev in list] [next in list] [prev in thread] [next in thread]