karn@jupiter.bellcore.com.UUCP (02/04/87)
Some time ago, there was discussion about IP implementations which respond inappropriately to broadcast packets. A number of solutions were offered, the best one (in my opinion) being a flag to tell IP when a packet was received on a hardware broadcast address so that it would not try to forward it or respond to it with an ICMP message. Since then, there seems to have been virtually no progress among the vendors in implementing these fixes. Here at Bellcore we run a rather large network consisting of Ethernets at several locations bridged together with DEC LanBridge 100's and Vitalink Translan-3s. With so many hosts on the same "virtual Ethernet", from time to time broadcast packets with bogus IP addresses are bound to appear. Right now there is one Microvax running Ultrix 1.2 that has its netmask set improperly. A single rwho packet from that machine triggers literally HUNDREDS (as counted with my Excelan Lanalyzer) of ARP requests. This represents practically every host on the network!! I cringe to think that before long many more of our machines will be running 4.3 BSD-derived code that allows the setting of the IP broadcast address to any bogus value the heart desires. At Uniforum in DC the other week I played with the Lanalyzer at the Excelan booth. Guess what? Most of the packets on the net were ARP requests because of one machine that didn't have its IP broadcast address set right! I felt right at home. At least I now know what to say the next time a vendor tells me "get our latest release and then call me back". Before somebody tries to tell me that it's my fault for using bridges on such a large scale, I should point out that the Vitalink boxes make it very easy to cut off misbehaving hosts. By entering the Ethernet address of the aforementioned Microvax into the bridge's "twit list", the offending traffic is isolated to one location. Even with these problems our use of bridging has improved our network's availability enormously over our old practice of using UNIX machines as IP gateways. It was worth it just to be able to get rid of routed (RIP) for internal communications. If something more formal than the TCP-IP archives is needed to get the vendors to act, I hereby volunteer to write the RFC. I would require that the link or subnet pass a "multicast" bit to IP indicating when an incoming packet is received on a hardware broadcast or multicast address. If this bit is set, IP must refuse to forward the packet or answer it with an ICMP message. It should also refuse to pass the packet up to TCP, should its protocol ID appear in the header. Naturally, the multicast bit would always be zero for packets received on non-broadcast and point-to-point subnets. Since there are so many incompatible conventions for IP broadcast addresses, I suggest that they be done away with altogether. Since gateways never forward broadcasts, the IP destination address in a broadcast UDP packet has no real meaning and should be ignored. The fact that the packet was sent to the hardware broadcast address should be enough to say "this is a broadcast packet". Phil
Mills@LOUIE.UDEL.EDU.UUCP (02/08/87)
Phil, The fuzzball gateways used on the NSFNET Backbone, among other places, incorporate a "martian filter" that grounds packets for the various IP braodcast addresses, as well as other reserved addresses (see RFC-990). At least one other gateway system (cisco) allegedly does the same. As you know from my previous messages to this list, gateways that forward IP broadcast packets can creat astonishing mischief in quite surprising places. Your suggestion on a mechanism to prevent forwarding of multicast packets was suggested to the INENG Task Force some time back; however, implementation in the various Unix bsd's hasn't happened yet. See also the appendix to RFC-985 for further suggestions. Your comments and advice on the issues raised there would be welcome. Dave