Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!ucsd!rutgers!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Why does a wrong broadcast address cause arp-havoc? Message-ID: Date: 14 Jul 90 10:02:03 GMT References: <1990Jul13.205833.7161@phri.nyu.edu> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 21 broadcasts cause arp storms because of a combination of over friendliness and confusion. Suppose you've got a system that things the broadcast address is 128.6.0.0 (an old 4.2 system). Now you have a system that sends using the correct broadcast address, which for my local subnet is 128.6.4.255. The old system will see this packet, since it's a broadcast. The IP input code will look, not recognize it as a broadcast, and assume that 128.6.4.255 is a host. Since most IP code is capable of acting as a gateway, it will assume somebody is trying to use it as a gateway, and thus try to forward the packet to 128.6.4.255. This will cause it to send an ARP request for 128.6.4.255. Another scenario is that you send a broadcast for 255.255.255.255 (the correct generic local broadcast). An old host may not recognize this as a broadcast. It will think this is a packet destined for network 255. Since it doesn't have a route to network 255, it may try to send back an ICMP unreachable. This will cause it to ARP the original sender. There are all sort of scenarios like this. They are complicated by various bugs. E.g. one implementation ended up sending ICMP errors to a broadcast address. What's really amusing is if somebody answer an ARP for 128.6.4.255 with a response giving Ethernet address ff.ff.ff.ff.ff.ff. In some sense this is right. However this can result in all sorts of mischief.