a proposed modification to ARP

John A. Shriver (jas@proteon.com)
Mon, 11 Jul 88 11:23:13 EDT

I think that moving the ARP boradcast to a Ethernet Multicast address
still assumes too much on the part of our overworked Ethernet
interfaces. 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.

All of these interfaces will have a much more difficult existence if
we change ARP to use a multicast. 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.

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.

I think that in most networks, more broadcast traffic is routing than
is ARP. RIP, rwho, ruptime, et. al. are the problem, not ARP.

Lets not design (or ad-hoc, as Berkeley did) ANY more physical
broadcast protocols. From now on, we use multicast. Does DCA want to
shell out the $1000 to IEEE for an address block? That will get us
2^24 multicast addresses of the IP community.

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