Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!pasteur!ucbvax!HOGG.CC.UOREGON.EDU!jqj From: jqj@HOGG.CC.UOREGON.EDU Newsgroups: comp.protocols.tcp-ip Subject: a proposed modification to ARP Message-ID: <8807092227.AA09479@hogg.cc.uoregon.edu> Date: 9 Jul 88 22:27:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 42 Abstract: ARP on Ethernet should use an Ethernet multicast address rather than the Ethernet broadcast address. As MAC-level bridges become more common and cheaper, the average size of a single logical Ethernet (the span of an Ethernet broadcast packet) is growing, as is the average number of machines on the Ethernet. Not all of these machines speak IP; DECnet, Novell IPX, XNS IDP, and several other protocols are extremely popular. Politeness dictates that one protocol not get in another's way. I think IP hosts should be grateful, for example, that DEC uses Multicast rather than broadcast for most DECnet "broadcasts", and hence that the typical IP-only host doesn't have to do any work to throw away DECnet traffic it doesn't care about. We aren't so polite -- we pollute the cable with ARP packets and IP broadcasts. As the networks get bigger, the cost of using broadcasts rises at least geometrically. 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. ARP, though, would be easy. I propose that a well-known Ethernet multicast address be reserved for ARP, and that it be used instead of the broadcast address. For backwards compatibility with existing implementations, presumably a multicast ARP that failed to generate a reply after a reasonable time would trigger an ARP to the broadcast address. Note that the imminent publication of a "how to be a perfect host" RFC makes this a propitious time for such an extension to the ARP spec. As a side benefit of moving ARP to multicast, one could then have an extended Ethernet with bridges that refused to pass broadcast packets, but that still looked to ARP and hence IP like one big network (note that IP does *not* require that IP broadcasts reliably get to all hosts on a network, or even require that IP broadcast be implemented. The one application I care about that uses IP broadcast, RIP, can easily be made to cope with a partial-broadcast Ethernet since the number of gateways << number of hosts). Breaking a big Ethernet into smaller broadcast domains clearly further reduces the problem of Ethernet broadcasts on an extended Ethernet. Comments?