Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!PARK-STREET.BBN.COM!tmallory From: tmallory@PARK-STREET.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP's & IP src addrs Message-ID: <8809211159.AA06217@ucbvax.Berkeley.EDU> Date: 19 Sep 88 14:03:56 GMT References: <23635@hi.unm.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 53 Now that the first wave is in, I'd like to amend the following: >Flame: An ICMP echo to a broadcast address should get no response! What an >incredibly obnoxious thing to do! My reply was motivated from my position as a user on a single relatively large ethernet(~500 hosts). There is no protection from this kind of barrage, although a single host could, in theory, use almost as much of the network bandwidth. If a large percentage of the replying hosts have to ARP for the sending host's hardware address, then that's a lot of ARP requests for everyone to process. I agree that a broadcast ping is a very simple and effective tool for network administration. Long before my message reached the rest of the world, I had received an internal reply to this effect. Aside from the usual list of benefits(unlisted hosts, trailer configured hosts, etc.), the reply pointed out that 'obnoxious' applied to the effects observed by users, and that a ping at two in the morning was unlikely to bother most people(at least here at BBN :-). Some problems: once the network gets large enough, there is a reasonable chance that not all of the replies will get back(so try a couple of times?). Also, it is not always possible to guarantee a 'safe' time to use such a tool. A user wishing to measure inter-machine performance will naturally schedule his test to run at two in the morning, when traffic is light... Nor is it simple, with the advent of work-stations, to prevent almost anyone from performing the 'what if' ping test. Many of us remember a much more public 'what if' test of the unix 'rwall' command a few years ago. Note also that the ping request can be sent through ip routers, which makes a great burst traffic generator to stress the routers, but leaves no protection for the poor users of both the network and the router. I am therefore arguing in favor of the spirit of the draft Host Requirements RFC(courtesy Steve Deering): According to the draft Host Requirements RFC, a host must silently ignore ICMP Echo and Timestamp Requests sent to an IP broadcast address. A host may (at the implementor's discretion) reply to an Echo or Timestamp Request sent to an IP multicast address, in which case the IP source address of the Reply is the address of the interface on which the Request arrived. By the routing rules in the Host Requirements RFC, that interface is also the one over which the Reply is sent. Actually, I don't have a great problem with hosts responding to such a request if they choose to, but if they do, then I believe it is important that the source address used be that over which the packet was received, rather than that over which it sends the reply, since that is the only way to establish the address that the host thinks it is using on the broadcast network of the echo request. (I'll need to read up on the routing rules before I go along with always replying back out the same interface.) Tracy Mallory