Path: utzoo!attcan!uunet!husc6!bbn!uwmcsd1!ig!agate!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.10.1314.590@pescadero.stanford.edu> Date: 10 Jul 88 20:14:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 50 I agree completely with the suggestion of using Ethernet multicast, instead of broadcast, for ARP. Not only would it reduce the unnecessary interrupt load on non-IP hosts, but it might also allow some IP hosts to disable reception of Ethernet broadcasts (which is possible with some Ethernet interfaces), thus avoiding everyone else's broadcast pollution. Whenever I have suggested this in the past, someone has always raised the point that not all Ethernet interfaces are capable of receiving specific multicast address. However, every interface that I have encountered provides at least the capability of receiving ALL multicasts; there may be interfaces in the PC world that don't even do that -- they could get by with the broadcast-on-retransmission scheme that you proposed for backwards compatibility. Modern Ethernet chips, such as the LANCE and the Intel chip, do provide the necessary multicast support, as must any interface that is expected to support DECnet or the new ISO protocols. I suggest that different Ethernet multicast addresses be used for ARP-for-IP, ARP-for-CHAOS, etc., to improve the precision of the multicast. A more radical suggestion for improving the precision (for which I cannot claim credit -- I regret that I have forgotten who suggested it to me) is to allocate a block of Ethernet addresses for ARP-for-IP, and define a mapping function from IP address into Ethernet address within the block. For example, say a block of Ethernet multicast addresses of the form A-B-C-?-?-? were set aside for this purpose. The IP address w.x.y.z could be defined to map to the Ethernet address A-B-C-x-y-z. A host wishing to resolve the address of w.x.y.z would send its ARP request to A-B-C-x-y-z. Only those hosts whose IP addresses end in x.y.z would need to listen to that Ethernet multicast address. Doing away with IP broadcasts might be hard. We don't yet understand the issues of IP multicast well enough to make it a required part of IP, but will probably end up with some fairly complex IP multicast; this suggests that we not hastily adopt a simple scheme that is not sufficiently general. In RFC-1054, I propose an IP multicasting scheme that could immediately replace all current uses of IP broadcast on directly-connected networks. Of course I am biased, but I believe that the host requirements specified in that RFC are not very complex -- the real complexity lies in the multicast routers, which are not necessary for multicasting to immediate neighbors only. As for its generality, I would welcome any and all comments on the proposed scheme. The End-to-End Protocols task force is promoting RFC-1054 as a possible Internet standard; if anyone is unhappy with the proposal, they should speak up now. Steve Deering