Steve Deering (firstname.lastname@example.org)
15 Jul 1988 14:02-PDT
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
188.8.131.52, to which all multicast-capable IP hosts are expected to
listen. Might as well conserve filter slots, where possible.
From David Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>:
I just barfed up my breakfast. Have they stopped teaching modularity
and functional boundaries in computer science classes?
Have they stopped teaching civility in kindergarten?
I'm not sure I agree. I'd like to keep ARP conceptually distinct from
IP, so as long as ARP is also used for Chaos and potentially for other
protocols, it would be desirable to have one more multicast address just
for it. ...
Sorry, I was less clear than I should have been. I was referring to the
use of ARP for IP addresses, as I mentioned in my first message. Clearly,
ARP for Chaos addresses should use a different multicast address, given
that the set of hosts running Chaos is not necessarily the same as the set
of hosts running IP.
The idea is that one Ethernet multicast address identifies the set of
all local hosts running IP. Any application that wishes to send to that
particular set of hosts should use that address, regardless of ether-type
or higher-level protocol (just as the unicast Ethernet address used to
reach a single host does not depend on the higher-level protocol [with the
unfortunate exception of DECnet]). Currently, both IP broadcast and ARP
use the same address, FF-FF-FF-FF-FF-FF, which identifies a larger set of
hosts than necessary; I have suggested a more accurate address to use.
In fewer words, link-level addressing is orthogonal to protocol type.
Of course, ARP-for-IP *could* use a different multicast address than that
used for the IP all-hosts group, but they would identify exactly the same
set of hosts. Given that most current Ethernet interfaces have a small,
fixed number of multicast filter slots or hash buckets, it's worthwhile
to avoid the redundancy.
(On the other hand, if you adopt the address hashing scheme we have been
discussing, the sets of ARP targets will differ from the set of all IP
hosts, so different multicast addresses are appropriate. In return for
using up another filter slot, you get many fewer unnecessary interrupts.)
When this same topic came up a year or so ago, David Plummer (the gentleman
with the vomit on his lap) objected to using multicast for ARP-for-IP, on
the grounds that ARP was independent of IP and should not need to know
anything specific to IP. (I regret that I no longer have a copy of his
message from that discussion; I'm sure he will correct me if I am
misrepresenting his objection.) In my view, the hardware-level destination
address is simply another parameter to ARP, just like the hardware and
protocol addresses that go in the ARP fields.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:42:51 GMT