IP Echo Host Service
RFC 2075

Document Type RFC - Experimental (January 1997; No errata)
Was draft-rfced-exp-partridge (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2075 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)
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.

Implementation Details

   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

      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, the IP source and
   destination are always exchanged and TTL and checksum updated, but in
   certain situations, other special actions may have to take place.

   If the datagram contains an incomplete source route option (i.e. the
   echo host is not the final destination), the datagram MUST be
   discarded.  If the datagram contains a complete source route option,
   the source route option MUST be reversed, and the datagram (with
   source and destination IP addresses exchanged and updated TTL) MUST
   be sent back along the reverse source route.

   More generally, the goal with any option is to update the option such
   that when the echoed packet is received at the original source, the
   option fields will contain data which makes sense for a datagram
   originating at the echo host.

   There is one option for which it is unclear what the correct action.
   The timestamp option is sometimes used for round-trip time
   estimation.  If the option is reset at the echo host, then a history
   of roughly half of the trip delay will be lost.  But if the option is
   not reset, then the timestamp option will appear inconsistent with
   the source and destination addresses of the datagram.  To try to
   balance these two issues, the following rules are suggested:

      1. If the first entry in the timestamp option contains the IP
      address of the source host, the entry SHOULD be rewritten to
      contain the IP address of the echo host, and the timestamp option
      pointer SHOULD be truncated so that this timestamp is the only one

Partridge                     Experimental                      [Page 2]
Show full document text