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