Path: utzoo!utgpu!watmath!iuvax!rutgers!bellcore!jupiter!karn
From: karn@jupiter (Phil R. Karn)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Using the 4.2 broadcast addr with 4.3 systems
Message-ID: <17528@bellcore.bellcore.com>
Date: 30 Aug 89 21:17:25 GMT
References: <8908290708.AA20139@ucbvax.Berkeley.EDU>
Reply-To: karn@jupiter.bellcore.com (Phil R. Karn)
Organization: Bell Communications Research, Inc
Lines: 26


I've said it before, and I'll say it again... the proliferation of IP
broadcast formats, the confusion about which to use, and the broadcast
storms that result from all this, tells me that there is a fundamental
flaw in how broadcasting is presently handled in IP.

I believe that the determination of whether a packet is a broadcast
packet should NOT be made from the IP destination address field, but
rather from the link layer destination field. If a datagram comes
encapsulated in an Ethernet frame with a destination of all 1's, then IP
should treat it as a broadcast packet, regardless of what it says in the
IP destination field.

This requires an "out of band" flag (indicating whether the link level
destination field contained a broadcast or multicast address) to be
passed up along with the packet so that IP's behavior can be
appropriately influenced. For example, ICMP would use this bit to
suppress ICMP error messages. Broadcast forwarding storms can't happen
since a hardware broadcast address on an IP datagram implies an IP
broadcast, and IP would never try to forward such a packet.

If you also pass this flag up to the transport layer, then it's easy for
TCP to ignore people trying to telnet to the broadcast address. Other
protocols, e.g., UDP, would accept broadcast packets.

Phil