Mon, 19 Sep 88 10:03:56 -0400
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
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.)
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:30 GMT