Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!think!ames!ucbcad!ucbvax!FALINE.BELLCORE.COM!karn
From: karn@FALINE.BELLCORE.COM (Phil R. Karn)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Ethernet meltdowns
Message-ID: <8707152300.AA06270@faline.bellcore.com>
Date: Wed, 15-Jul-87 19:00:11 EDT
Article-I.D.: faline.8707152300.AA06270
Posted: Wed Jul 15 19:00:11 1987
Date-Received: Sat, 18-Jul-87 01:34:49 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 19

As I've said before, I think the notion of an "IP broadcast address" is
utterly meaningless. Broadcasting is a notion limited solely to certain
subnets; the Internet itself has no notion of broadcasting. (I'll ignore
the experimental multicast work for the time being).

Therefore it is completely bogus to look at anything other than the
SUBNET destination address when determining whether an incoming packet
is a broadcast or not. Getting an Ethernet packet with all 1's in the
destination field is both necessary and sufficient to label it as a
broadcast packet that must not be forwarded or answered with an ICMP
message even if the type field says it's an IP datagram. The IP address
field should be completely ignored; therefore it is irrelevant to even
specify a "standard" IP broadcast address.

It is arguable whether broadcast packets should even use UDP/IP at all,
although I suppose it is handy because of the port multiplexing and
checksumming provided by UDP.

Phil