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