Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!UDEL.EDU!Mills
From: Mills@UDEL.EDU.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  ICMP in ISO
Message-ID: <8704171132.a018567@Huey.UDEL.EDU>
Date: Fri, 17-Apr-87 11:32:40 EST
Article-I.D.: Huey.8704171132.a018567
Posted: Fri Apr 17 11:32:40 1987
Date-Received: Sat, 18-Apr-87 06:10:42 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 20

Greg,

In a random search I found about half the dozen of so hosts I tried did
respond to the TCP Echo port, including all the 4.2s and 4.3s I tried
(but not the Suns). At least one Multics machine and all the Fuzzballs I
tried responded as well. The SATNET SIMPs have long been used as a tool
to debug reassembly implementations, since SATNET can fragment and
dis-order datagrams in glorious ways. Nevertheless, your comment is
accurate in that the TCP/UDP Echo service is certainly not ubiquitous.

It is interesting to note that a TCP/UPD Echo service is trivial to
implement, since all it takes is a swap of addresses (and ports in some
implementations), which makes it no more intrusive than ICMP Echo.
However, this defeats the purpose of the service, which is to verify
that the TCP/UPD protocol layer itself is working properly. An interesting
side issue is exactly how the echo service is implemented with respect
to source-route, record-route, TTL and so forth. Exploration of this
may shed some lumens on the general protocol model as well.

Dave