Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!ISI.EDU!braden From: braden@ISI.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP echo Message-ID: <8704272025.AA00279@braden.isi.edu> Date: Mon, 27-Apr-87 16:25:43 EDT Article-I.D.: braden.8704272025.AA00279 Posted: Mon Apr 27 16:25:43 1987 Date-Received: Wed, 29-Apr-87 01:06:42 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 34 Hi. You have asked a question about ICMP Echo semantics that ought to be, but isn't, contained in the RFC985-revision. Sigh. Here is my totally-prejudiced view on how ICMP Echo should behave (it is the way my own TCP/IP code implemented ICMP Echo, of course!). Anyone who wants to beat me up about this should do so now... otherwise, this interpretation is likely to find its way into the gateway specification RFC. A host or gateway D that receives an ICMP Echo Request addressed to itself from host S should send an ICMP Echo Reply back to S, using the following rules: 1. If the Echo Request contained no source route, the Reply should be sent to S using the normal routing rules of D. As a result, the Reply may come back by a different path than the Request took. 2. If the Echo Request did contain a source route, the Echo Reply will be sent using the return-route built up in the source-routing option of the Echo Request. As a result, it is not possible to force a route for the Reply which is different from the route used for the Echo. A result of these rules is that ICMP Echo can be used to sample the complete round-trip path which any other higher-level protocol e.g., TCP) will use for its data and ACK packets between D and S. The rules generally follow from the assumption that ICMP is a protocol parallel to TCP and above IP, and needs no special routing mechanism. Bob Braden