Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!PESCADERO.STANFORD.EDU!deering
From: deering@PESCADERO.STANFORD.EDU (Steve Deering)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  ICMP echo
Message-ID: <87.04.28.1027.510@pescadero.stanford.edu>
Date: Tue, 28-Apr-87 13:27:00 EDT
Article-I.D.: pescader.87.04.28.1027.510
Posted: Tue Apr 28 13:27:00 1987
Date-Received: Sat, 2-May-87 04:59:15 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 27


    From: CLYNN@G.BBN.COM :
    I would argue that the simplest implementation is the most useful --
    just change echo request to echo reply and switch the IP source
    and destination and send the packet back...

    From: Mills@UDEL.EDU :
    Your [Bob Braden's] model, taken prima facie, implies the respondent
    simply flips the IP addresses and source-route and tosses it back in
    the net, presumably leaving the options alone. I think this is the right
    thing, but believe it should be explicitly stated.

Although the ICMP spec does say to simply reverse the IP source and
destination addresses, that is incorrect when the original IP destination
is a multicast or broadcast address.  In that case, the IP source address
of the Echo Reply (or Timestamp Reply, Information Reply, or Address Mask
Reply) should be set to one of the replying host's individual addresses
(presumably the one corresponding to the interface from which the reply
is sent).  I realize that many of you already know this, but it is a
common bug and this seemed like a good opportunity to point it out.

Let me also remind people that ICMP *error* messages (i.e., Destination
Unreachable, Source Quench, Redirect, Time Exceeded, or Parameter Problem)
should never be sent in response to a packet with a multicast or broadcast
IP destination.

Steve Deering