Path: utzoo!utgpu!watmath!att!dptg!rutgers!bellcore!ka9q.bellcore.com!karn
From: karn@ka9q.bellcore.com (Phil Karn)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Using the 4.2 broadcast addr with 4.3 systems
Message-ID: <17535@bellcore.bellcore.com>
Date: 31 Aug 89 03:39:05 GMT
References: <8908290708.AA20139@ucbvax.Berkeley.EDU> <17528@bellcore.bellcore.com> <3801@mentor.cc.purdue.edu>
Sender: news@bellcore.bellcore.com
Reply-To: karn@ka9q.bellcore.com (Phil Karn)
Organization: Secular Humanists for No-Code
Lines: 22

>	What about directed broadcasts? If you remove the idea of a broadcast
>address from IP, you lose this. Maybe you see that as an advantage... :-)
>	I'm not really sure what you mean by "making it a flag", though; I
>presume you mean in the uppermost interface of IP, but perhaps you mean
>something in the packet. (?) The latter wouldn't seem much different than
>a broadcast address, since all but the "real" addressee would reject it,
>unless it were some special address, anyway.

By "flag", I mean that the subnetwork should pass an indication of whether
the packet was received on a hardware broadcast or multicast address up to
the IP layer along with the packet, e.g., as a second argument in a function
call.

My scheme doesn't really preclude multicasting. My main goal was to find a
reliable way to stop broadcast and ARP storms even when other hosts have
totally broken notions of the IP broadcast address.  As long as the hardware
multicast flag is available to IP, the IP layer can suppress the ICMP
messages and packet forwarding that cause broadcast storms; it can still
look at the IP destination address if it wants to see if the packet should
be accepted locally.

Phil