a proposed modification to ARP


jqj@hogg.cc.uoregon.EDU
Sat, 9 Jul 88 15:27:57 PDT


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?



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