Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!QUABBIN.SCRC.SYMBOLICS.COM!DCP
From: DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: multicast groups on ether
Message-ID: <870406101639.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Mon, 6-Apr-87 09:16:00 EST
Article-I.D.: KOYAANIS.870406101639.2.DCP
Posted: Mon Apr  6 09:16:00 1987
Date-Received: Wed, 8-Apr-87 03:40:55 EST
References: <87.04.03.1555.090@pescadero.stanford.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 46
Approved: tcp-ip@sri-nic.arpa

As I think some people have already tried to state, ** There is now
standard for multicast addressing **.  The only thing the blue Ethernet
book says is that multicast addresses exist and here's what they look
like.  It does not say what functinality implementors of hardware
interfaces should provide.  It doesn't give any hints if implementations
should allow filters on the top 24 bits, or the bottom 8 bits, or
anything.  Therefore, what Interlan does is different than what 3Com
does which is different than what DEC does which is different.... 
Please don't go inventing ideas that work well on only one type of
interface.

I also suggest people separate network level packets like ARP from
protocol like packets like RWHO, TFTP and Time.  They are very different
and you may find that the "solution" for each is different.

I'm against adding IP-specific things to the handling of ARP.  ARP is
blatently non-IP specific (non-anything specific for that matter) and I
fear putting in non-modular hooks between the layers will burden
multi-protocol operatins systems at the expense of single-protocol
systems.  Additionally, it isn't easy to extend ARP to be Ethernet
specific (e.g., have ARP-for-IP and ARP-for-CHAOS) since ARP doesn't
know anything about Ethernet nor about IP and wouldn't know what to do
if you told it.

I conjecture that if there are excessive ARP packets on your cable, than
one of two things is happening: Some station's cache isn't big enough
(simple enough to solve), or some station isn't responding.

XNS, Pup and Chaos routing present a constant (though supposedly
low frequency) stream of broadcast packets.  Multicast would probably be
a good thing here, if we could figure out how multicast should work.

RWho in my opinion should be flushed.  It is an unsolicited
user-level protocol.

Time is (or should be) a solicited user-level protocol.  I'd be
surprised if it really caused excessive burden.

Domain Name lookups are broadcast?  New one on me.

How often does BOOTP really happen?  If the BOOTP protocol isn't able to
latch on to the server address directly, I suggest the BOOTP protocol be
changed to do so.  A PDP-11 netboot protocol I wrote 5 years ago did
indeed broadcast the initial request and then latched onto the server.
Everybody is burdened with one, perhaps two, packets and then never
hears from the booter again.