Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!rutgers!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP's & IP src addrs Message-ID: Date: 17 Sep 88 01:23:10 GMT References: <23634@hi.unm.edu> <8809151450.AA23101@ucbvax.Berkeley.EDU> <23635@hi.unm.edu> <24915@bu-cs.BU.EDU> Distribution: na Organization: Rutgers Univ., New Brunswick, N.J. Lines: 17 We've certainly been bitten by hosts that respond to broadcasts inappropriately, so I'm sympathetic with the idea of being very conservative in responding to ICMP broadcasts. But let's not go too far. Kent England says you are never allowed to respond to a broadcast by sending an ICMP, even if the source of the broadcast is an ICMP. I think what should be said is that you never respond to a broadcast by sending an ICMP *error* message. If the original broadcast is one of the ICMP queries, and the query is well-formed, you can certainly send the corresponding response. Otherwise you couldn't broadcast an ICMP net mask request and expect to get a response. I have mixed feelings about broadcast ICMP echo requests. If you do it very much, it could produce very bad results. However I can also think of situations where I would want to be able to do it. So I'm inclined to say that it should be legal to respond to a broadcast ICMP echo request. If the host requirements RFC says what you said, I think Bob Braden should think again. Either that or come up with some other way to find out your net mask...