multicast groups on ether

[dee...@pescadero.stanford.edu.uucp]

The goal is to completely eliminate use of the broadcast address. TCP/IP
implementations may be overusing this feature, between ARP, RWHO, etc.

Hear! hear! At the moment, if you want to use IP on an Ethernet, you
must listen to Ethernet broadcasts, for the sake of ARP. Here at
Stanford, that means you get to receive and discard packets broadcast
for RWho, Reverse ARP, RIP, TFTP, Time, Domain Name lookups, Pup name
lookups, BOOTP, ND, Pup routing, XNS routing,... and whatever new
broadcast protocol was invented today.

In RFC988, I propose a way to manage multicast addresses for IP-based
applications. I suggest that the number czar should allocate well-known
IP multicast address, rather than Ethernet multicast addresses, and that
there should be a standard mapping from IP to local network multicast
addresses for each type of local network.

As for ARP, I think ARP-for-IP should use a different Ethernet multicast
address than ARP-for-Chaos or ARP-for-whatever, even though they use the
same Ether-type. And, of course, Reverse ARP should use different
addresses than ARP.

To phase in multicast-based ARP, you could (during the phase-in period)
listen to both the broadcast address and the multicast address. When
sending an ARP request, use the multicast address first, then broadcast
if you don't get a reply.

Karen Lam of BBN has extended the 4.3bsd UNIX IP code to support
RFC988-style multicasting, on top of which I have implemented a
multicast version of Berkeley's rwho daemon. This code (both Karen's
and mine) is running successfully at a couple of test sites and I hope
it will soon be made available for wider distribution to those who wish
to experiment with IP multicasting.

I would appreciate any feedback on RFC988. I would also like to hear
of any other work going on in the area of internetwork multicasting.
In particular, is the x3s33 committee considering internetwork multicast
addressing and routing?

Steve Deering

[D...@quabbin.scrc.symbolics.com.uucp]

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.