Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pasteur!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.15.1402.140@pescadero.stanford.edu> Date: 15 Jul 88 21:02:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 57 From me: 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 224.0.0.1, to which all multicast-capable IP hosts are expected to listen. Might as well conserve filter slots, where possible. From David Plummer: 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? From jqj@hogg.cc.uoregon.EDU: 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. Steve Deering