Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!CCV.BBN.COM!brescia From: brescia@CCV.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: multicast groups on ether (was: danger of bridges) Message-ID: <8704031719.AA28257@ucbvax.Berkeley.EDU> Date: Fri, 3-Apr-87 11:52:45 EST Article-I.D.: ucbvax.8704031719.AA28257 Posted: Fri Apr 3 11:52:45 1987 Date-Received: Sun, 5-Apr-87 03:43:26 EST References: <8704030214.a001249@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Do you have a concrete suggestion on how to manage the multicast group? How about the following (summary: manage by czar). The goal is to completely eliminate use of the broadcast address. TCP/IP implementations may be overusing this feature, between ARP, RWHO, etc. Go to the ethernet number czar and get two (2) groups of 65536 (2^^16) multicast addresses. By that, I mean the high order 32 bits are assigned by the czar, and the low 16 bits are ours to play with. Call the first group and the second group . These become well know, and wired in the programs, much like 255.255.255.255.255.255 is today. The first group, , is the contact address for all hosts which handle 'broadcast' for a particular ether link (message type). Thus ARP, instead of polluting all the hosts in the net, would send to the address .8.6 (0x0806 is the number assigned to the address resolution protocol). The second group, is the set of addresses for IP broadcast protocols, and subdivided into one byte of IP protocol (e.g. UDP, 17), and one byte of well-known-port (e.g. RWHO, 550 (oops, well, you get the idea). While this idea is a bit half-baked, it should serve to move host and gateway impementations to independence from broadcasts.