Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!esosun!ucsdhub!sdcsvax!ucbvax!UDEL.EDU!Mills
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  ICMP echo
Message-ID: <8704280104.a006354@Huey.UDEL.EDU>
Date: Tue, 28-Apr-87 01:04:55 EDT
Article-I.D.: Huey.8704280104.a006354
Posted: Tue Apr 28 01:04:55 1987
Date-Received: Wed, 29-Apr-87 05:42:25 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 29

Bob,

Your model is the one I understand to be in common use, although only the
TOPS-20 is known to me to implement the return route in the way you
suggest (are there others?). However, there is still the question of
options, such as security, etc. Your 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.

On the question of reciprocal routes, unless the ICMP Echo message
was explicitly source-routed, the return route will not necessarily
fly back the reciprocal path. Ordinarily one might expect this and,
indeed, there are many well-behaved segments of the Internet where this
is so. However, in the flooding NSF swamps it has been my observation
that routes are reciprocal only sometimes. In such cases it would be
useful to have an enriched record-route facility. A sneaky way to do
this might be to simply continue the record-route past the echo server.

A final tid: Should the TTL be reset at the echo server? If not, the
sender would have a non-ambiguous way to measure the number of hops.
He could, of course, also use record-route.

Finally, how about a new ICMP Echo/Echo Reply message that operates
as the present one, but where the echo server captures the IP header,
etc., in the same way as ordinary ICMP error messages before returning
to sender?

Dave