Re: udp packet storms

[mike_raffety () il us swissbank com (Mike Raffety)]

> The RFCs specify that you must never respond to an ICMP request with a
> broadcast. However, this may work with UDP echo ports on hosts with
> defective behavior of the sort we've just been noting.

When doing broadcast pings (for network debugging), I've regularly
noticed a number of the, umm, less-than-solid IP stacks make this mistake.
If a network is half Suns and half PCs, the PCs often respond with a source
broadcast address.

I'm sure they're doing this because the ICMP ECHO code simply swaps the
source and destination addresses, sets the ICMP type, and returns the
packet.

As someone else pointed out though, with ICMP ECHO (ping), you won't
get storms because the return packet is an ICMP ECHOREQUEST, a completely
different type of packet.

The relevant question, I think, is with respect to the RFC defining the
UDP echo service; does it say that it should never respond with a
broadcast address?  Below is the COMPLETE RFC (RFC 862).  I think it's
safe to say that the "correct" behavior with respect to broadcasts is
unspecified.

----- Begin RFC -----

This RFC specifies a standard for the ARPA Internet community.  Hosts on
the ARPA Internet that choose to implement an Echo Protocol are expected
to adopt and implement this standard.

A very useful debugging and measurement tool is an echo service.  An
echo service simply sends back to the originating source any data it
receives.

TCP Based Echo Service

   One echo service is defined as a connection based application on TCP.
   A server listens for TCP connections on TCP port 7.  Once a
   connection is established any data received is sent back.  This
   continues until the calling user terminates the connection.

UDP Based Echo Service

   Another echo service is defined as a datagram based application on
   UDP.  A server listens for UDP datagrams on UDP port 7.  When a
   datagram is received, the data from it is sent back in an answering
   datagram.

----- End RFC -----