Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!pescadero.stanford.EDU!deering
From: deering@pescadero.stanford.EDU (Steve Deering)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: a proposed modification to ARP
Message-ID: <88.07.12.2125.510@pescadero.stanford.edu>
Date: 15 Jul 88 00:50:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 93

[This message seems not have made it out to the tcp-ip list, so this
 is a retransmission.  Sorry if anyone gets a duplicate.  -- Steve]

	From Thomas Narten:
	Is broadcast traffic associated with ARP responsible for so much
	traffic that it must be stamped out? ...

ARP has often been responsible for broadcast storms, which some people
would like to stamp out.  Moving it to from broadcast to multicast
would reduce the number of potential victims of a storm (especially
if using an address hashing scheme, as I proposed).

Even when ARP is behaving itself, there is a pollution argument against
using broadcast: no single (well-behaved) broadcast application causes a
significant burden on uninterested hosts, but as the number of broadcast
applications continues to grow, and the number of hosts running those
applications on a single (possibly bridged-)LAN continues to grow,
the cumulative burden becomes serious.  To control it, you have to try to
stop as many offenders as possible.

It seems to me that the cost of cleaning up this pollution is almost
negligible, unlike the cost of cleaning up coal-burning factories or
semiconductor fabrication facilities or cars.  Just replace one
48-bit address with another, and set your multicast filter accordingly.

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

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
224.0.0.1, to which all multicast-capable IP hosts are expected to
listen.  Might as well conserve filter slots, where possible.

Steve