IP Echo Host Service (RFC2075)
Original Publication Date: 1997-Jan-01
Included in the Prior Art Database: 2019-Feb-16
Internet Society Requests For Comment (RFCs)
This memo describes how to implement an IP echo host. IP echo hosts send back IP datagrams after exchanging the source and destination IP addresses. This memo defines an Experimental Protocol for the Internet community.
Network Working Group C. Partridge Request for Comments: 2075 BBN Category: Experimental January 1997
IP Echo Host Service
Status of this Memo
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
This memo describes how to implement an IP echo host. IP echo hosts send back IP datagrams after exchanging the source and destination IP addresses. The effect is that datagrams sent to the echo host are sent back to the source, as if they originated at the echo host.
An IP echo host returns IP datagrams to their original source host, with the IP source and destination addresses reversed, so that the returning datagram appears to be coming from the echo host to the original source. IP echo hosts are tremendously useful for debugging applications and protocols. They allow researchers to create looped back conversations across the Internet, exposing their traffic to all the vagaries of Internet behavior (congestion, cross traffic, variable round-trip times and the like) without having to distribute prototype software to a large number of test machines.
IP echo hosts were heavily used on the Internet in the late 1970s and early 1980s to debug various Internet transport and application protocols. But, for reasons unclear, at the current date there are no echo hosts on the Internet and few people are even aware of the concept. The goal of this memo is to document the concept in the hopes it will be revived.
While the basic idea of a echo host is simple, there are a few implementation details that require attention. This section describes those implementation details. The presentation works from the simplest to most difficult issues.
Partridge Experimental [Page 1]
RFC 2075 IP Echo Host Service January 1997
The most straightforward situation is when an echo host receives an IP datagram with no options and whose protocol field has a value other than 1 (ICMP). In this case, the echo host modifies the header by exchanging the source and destination addresses, decrements the TTL by one and updates the IP header checksum. The host then transmits the updated IP datagram back to the original source of the datagram.
NOTE: If the TTL is zero or less after decrementing, the datagram MUST not be echoed. In general, an echo host is required to do all the various sanity checks that a router or host would do to an IP datagram before accepting the datagram for echoing (see STD 3, RFC 1122, and RFC 1812).
The TTL MUST be decremented for security reasons noted below. Observe, however, that the effect is that hosts using an echo path through an echo host SHOULD set their TTL to twice the normal value to be sure of achieving connectivity over the echo path.
If an arriving IP datagram has options, the echo host’s responsibilities are more complex. In general...