Re: a proposed modification to ARP

Steve Deering (
12 Jul 1988 21:25-PDT

But, as John Shriver points out:

        ... There are still interfaces that have no multicast filter,
        only mutlicast on/off (SEEQ chip, used on 3C501). There are
        interfaces with a severely limited number of multicast filters (the
        ones that don't use hash tables). There are interfaces whose
        performance plummets when you enable any multicast address, because
        they do a linear search of the table on every packet.

That's unfortunate, but does that mean everybody with a decent filter
has to continue to suffer? If the users of a particular interface find
that accepting all multicasts is too burdensome, they can continue to
accept only broadcasts, as long we specify that ARP retransmissions be
sent as broadcasts, and the retransmission interval is reasonably short.
Furthermore, the lack of a decent filter does not prevent them from
*sending* multicast ARP requests. I don't think that we should let
the weaknesses of these obsolete interfaces prevent us from moving
forward, especially given that we can accomodate them well enough until
they are replaced.

        ... The ones that have only on/off will be even more burdened, not
        only will they receive ARP (and rwho), now they will receive all
        the DECnet routing traffic they never wanted to hear. This will
        keep their single receive buffer constantly full of rubbish, so
        that the real traffic will never get in.

But it's OK to make the DECnet hosts receive all the IP rubbish they
never wanted to hear?

        ARP is in a lot of PROMs now, and PROMs are "forever". It's probably
        too late. People have too much invested in PROMs and interfaces to
        try changing ARP.

As pointed out, old implementations would continue to work.

        ... Does DCA want to shell out the $1000 to IEEE for an address
        block? That will get us 2^24 multicast addresses [for] the IP

It has already been done. 2^23 of them have been allocated to IP multicast
(see RFC-1054). The other half are reserved by the Internet Numbers Czar
for possible future uses, of which ARP might conceivably be one.

        From Drew Daniel Perkins:
        I'm not sure if you are really suggesting using 2^24 multicast
        addresses or not. While quite precise, it would probably be be
        overkill. Considering that many (most?) of the ethernet chips
        which support more than 1 multicast address actually support 64,
        a good compromise between only 1 address and 2^24 addresses might
        be to reserve 64. ...

You are right, you can hash to as many or as few addresses as you want,
but I don't understand what the size of an address filter has to do with
it -- each host need listen to only one multicast address for ARP, the
one to which its own IP address hashes (unless the host has more than
one IP address assigned to a single interface). The algorithm I suggested
gives a perfect hash and is trivial to implement. 2^24 is actually the
unit of allocation of multicast addresses from the IEEE; as John Shriver
mentioned, such a block of addresses costs $1000. (What a numbers racket!)
Alternatively, you could apply to the Numbers Czar for a smaller block --
only .006 cents an address :-)

By the way, if you decide to use only a single Ethernet multicast
address for ARP, I suggest that you use 01-00-5E-00-00-01. That is
the Ethernet address that corresponds to the IP multicast address, to which all multicast-capable IP hosts are expected to
listen. Might as well conserve filter slots, where possible.


This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:42:51 GMT