Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ucla-cs!ames!ucbcad!ucbvax!PESCADERO.STANFORD.EDU!deering
From: deering@PESCADERO.STANFORD.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: multicast groups on ether
Message-ID: <87.04.03.1555.090@pescadero.stanford.edu>
Date: Fri, 3-Apr-87 18:55:00 EST
Article-I.D.: pescader.87.04.03.1555.090
Posted: Fri Apr  3 18:55:00 1987
Date-Received: Sun, 5-Apr-87 07:37:49 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 40
Approved: tcp-ip@sri-nic.arpa


    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