Re: a proposed modification to ARP


Steve Deering (deering@pescadero.stanford.edu)
10 Jul 1988 13:14-PDT


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



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