RFC 2075

IP Echo Host Service 🎀

okay bestie, let's start with the paperwork 📋 (the title block, so you know who's involved):

• RFC number: 2075 ✨
• Title: IP Echo Host Service
• Network Working Group: this one was written for the Network Working Group 🌸
• Author: Craig Partridge, BBN 🧚
• Category: Experimental 🧪
• Date: January 1997 📅
• Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🤷

---

Status of this Memo 📣

So this memo defines an Experimental Protocol for the Internet community 🧪. It is not an Internet standard of any kind 🙅. Discussion and suggestions for improvement are totally requested 💬. Distribution of this memo is unlimited 🌈.

Abstract 🦋

This memo explains how to build an IP echo host. IP echo hosts send back IP datagrams after swapping the source and destination IP addresses 🔁. The effect is that datagrams you send to the echo host get sent back to you, like they came from the echo host itself 🪞.

Introduction 💖

An IP echo host sends IP datagrams back to their original source host, with the IP source and destination addresses reversed. That way the returning datagram looks like it's coming from the echo host to the original source 📮. Echo hosts are tremendously useful for debugging applications and protocols 🔍. Researchers can make looped-back conversations across the Internet, which exposes their traffic to all the chaos of Internet behavior (congestion, cross traffic, variable round-trip times and more) 🌪️. And they don't have to ship prototype software to a bunch of test machines 💅.

IP echo hosts were used a LOT on the Internet in the late 1970s and early 1980s to debug various transport and application protocols 📼. But for reasons nobody can really explain, there are currently no echo hosts on the Internet, and few people even know the concept exists 😭. The goal of this memo is to write the concept down so it can get revived 🫶.

Implementation Details 🛠️

The basic idea of an echo host is simple, but there are a few implementation details that need attention 🧠. This section goes from the simplest issues to the hardest ones 🪜.

The most straightforward case is when an echo host receives an IP datagram with no options, and the protocol field has a value other than 1 (ICMP) 🍓. Here, the echo host swaps the source and destination addresses, decrements the TTL by one, and updates the IP header checksum ✏️. Then it transmits the updated datagram back to the original source 📤.

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 hosts using an echo path through an echo host SHOULD set their TTL to twice the normal value, so they're sure to get connectivity over the echo path 🛣️.

If an arriving IP datagram has options, the echo host's jobs get more complicated 🌀. In general, the IP source and destination are always swapped, and the TTL and checksum get updated. But in certain situations, other special actions may have to happen 🎭.

If the datagram has an incomplete source route option (meaning the echo host is not the final destination), the datagram MUST be discarded 🗑️. If the datagram has a complete source route option, the source route option MUST be reversed, and the datagram (with source and destination IP addresses swapped and updated TTL) MUST be sent back along the reverse source route 🔙.

More generally, the goal with any option is to update it so that when the echoed packet gets back to the original source, the option fields contain data that makes sense for a datagram that originated at the echo host 🧩.

There's one option where the right action is unclear 🤔. The timestamp option is sometimes used for round-trip time estimation ⏱️. If the echo host resets the option, a history of roughly half the trip delay gets lost 💔. But if it doesn't reset the option, the timestamp option will look inconsistent with the source and destination addresses of the datagram 😬. 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 in the list. (This rewrite makes the option look consistent with the new source and destination IP addresses, keeps the source timestamp, and loses information about the path to the echo host ✂️.)
2. If the first entry in the timestamp option does not contain the IP address of the source host, the entry SHOULD be echoed back unchanged. The echo host SHOULD NOT appear in the timestamp option. (This approach keeps the entire history of the path, though on a symmetric route, every router may show up twice 👯.)

Finally, if the IP datagram contains an ICMP packet (meaning the IP protocol field value is 1), the datagram SHOULD be discarded 🚫. The reason: the most likely reason to receive an ICMP datagram is that an echoed datagram ran into a problem at some router on the path, and that router sent back an ICMP datagram 🚧. Echoing the ICMP datagram back to the router may confuse the router, so this SHOULD be avoided 🙈. (This rule just follows the Internet maxim of being conservative in what we send 🧸.)

Sometimes, though, the ICMP datagram has useful info for the source host that would be nice to echo ✨. A sophisticated echo host MAY choose to echo ICMP datagrams according to these rules:

1. Any ICMP datagram where the destination address in the encapsulated IP header (the header inside the ICMP datagram) matches the source address of the ICMP datagram MAY be safely echoed 🛡️.
2. ICMP Source Quench and ICMP Destination Unreachable with a code of 4 (fragmentation needed and DF set) MAY be sent to the destination of the encapsulated IP datagram, if the source IP address of the encapsulated IP datagram is that of the echo host. When the ICMP message is sent on, it SHOULD be rewritten as an ICMP message from the echo host to the source 🪄.
3. All other ICMP messages MUST be discarded 🧹.

These rules try to make sure end-to-end ICMP messages get through, along with messages from routers that are fairly safe and useful (or necessary) for the end system 📬. But potentially dangerous messages, like Redirects, get suppressed 🚷. (The ICMP Destination Unreachable with code 4 is required for MTU discovery under RFC-1191 📏.)

Security Considerations 🔐

Okay, this section is serious, so read it carefully 🚨.

Echo hosts pose a number of security concerns related to address spoofing 🎭.

First, echo hosts give obvious ways to extend attacks that use address spoofing 😈. A malevolent host can write a third party's IP address as the source address of a datagram sent to an echo host, and cause the echo host to send a datagram to that third party 📨. In general this trick doesn't create a brand-new security hole (the malevolent host could've just sent the datagram with a forged source address straight to the third party) 🤷. But there are some new twists to the problem 🌀.

One exception: the echo host is a host inside a firewall that accepts datagrams from hosts outside the firewall 🧱. In that case, a malevolent host outside the firewall might use the echo host to make its packets look like they come from inside the firewall (from the echo host) 👀. In general, a good firewall catches these cases, because the source address of datagrams sent to the echo host will be for a host inside the firewall, and testing for interior source addresses on datagrams arriving at an exterior interface is a standard firewall filter 🛑. But since the main purpose of echo hosts is wide-scale Internet testing, there's no reason to invite danger 🙅‍♀️. So we recommend that echo hosts SHOULD NOT be placed inside firewalls 💀.

Second, address spoofing can be used to flood the network 🌊. Here, a malevolent host sends a datagram to an echo host with the source address of another echo host. This trick makes datagrams circulate between the two echo hosts 🔄. The requirement that the echo host decrement the TTL by one makes sure each datagram eventually dies, but a sufficiently malevolent host sending lots of datagrams with high TTLs to an echo host can cause serious disruption 😱. There are a number of possible fixes (like requiring sources to authenticate themselves before sending datagrams to be echoed) 🔑. A simple protection is to limit the number of packets echoed back to any one source per second 🚦. For instance, you might limit a source to a packet rate equal to 10% of the interface bandwidth (for a 10 Mb/s Ethernet, that's about 75 maximum sized packets per second) 🧮.

One variation of this attack is to generate e-mail addressed to the echo host (e.g., user@echo.xxx.com) 📧. This e-mail loops around the network a bunch of times until the SMTP server decides the message has too many Received-From: lines 🔁.

A third variation of the flooding trick is to put a multicast or broadcast address as the source of the IP datagram sent to an echo server 📡. Since this creates an illegal arriving IP datagram, the echo server MUST discard the datagram 🚮. (This warning is a reminder that echo servers MUST do the standard checks for an illegal datagram before echoing 📝.)

Implementation Note 🧁

Echo hosts are often built as virtual interfaces on an existing host or router 🖥️. You can think of the echo host's IP address as a second IP address for the host, where all datagrams sent to that address get echoed 🪞. Here's a sneaky mistake to watch out for: when an echo host is a module inside a larger host implementation, it's easy to accidentally put the non-echo address of the host into an echoed packet 😵. For a variety of reasons (including security and correct operation of echo paths), implementors MUST ensure this NEVER happens 🚨💅.

Acknowledgements 🫶

This memo was sparked by a conversation with Jon Crowcroft, where they both lamented the demise of some beloved IP echo hosts (e.g., goonhilly-echo.arpa) 😢. It got a lot better thanks to comments from various members of the End2End-Interest mailing list, including Bob Braden, Mark Handley, Christian Huitema, Dave Mills, Tim Salo, Vern Schryver, Lansing Sloan, and Rich Stevens 🌟.

The author is emphatically not the inventor of echo hosts 🙅. Enquiries to the usual suspects suggest echo hosts were created by persons unknown (probably at BBN) very early in the development of IP 🕵️. The author would like to thank those persons who created echo hosts and apologize for any errors in describing their invention 🙏💜.

Author's Address 📬

Craig Partridge BBN Corporation 10 Moulton St Cambridge MA 02138

EMail: craig@bbn.com 💌