Why do some common traceroute implementations default to using UDP probes?

Question

I was recently troubleshooting a network connectivity meta-problem, in that I knew a given destination was reachable, but I was not able to demonstrate that with traceroute because the path went cold after a certain number of hops. Given that the last observed hop was just upstream from the node of interest, I sniffed the traffic, expecting to confirm that the probes were reaching it and to learn which filter rule was blocking them. Sure enough, I learned that the probes were UDP datagrams destined for a high (and varying) port that I had, of course, blocked to inbound traffic.

This surprises me, because I assumed that all traceroute probes would default to ICMP, since the responses are ICMP. I did a documentation survey and found that different implementations make different choices, and some do not allow the user to make a non-default selection.

• UDP
  • Cisco
  • Linux
  • FreeBSD
• ICMP
  • Juniper
  • Brocade
  • Windows

The abstract of Traceroute probe method and forward IP path inference supports my intuition that ICMP probes will more often succeed in reaching the destination.

Allowing different probe methods seems like a great idea, but defaulting to something other than ICMP seems like a bad idea. Could somebody describe the rationale behind why it is better to use UDP by default?

Answer 1

The first version of traceroute was written by Van Jacobson and it used ICMP but it didn't work very well. The vendor interpretation of ICMP in RFC792 was that routers should not send an ICMP error message in response to an ICMP packet (see edit notes below). Therefore most routers would not send a "time exceeded" message in response to an echo request with a TTL of 1 or 0. So he changed it to use UDP and lo and behold it worked great and there was much rejoicing (and adoption). The traceroute tool on Linux and FreeBSD (and I assume Cisco) is based on Van Jacobson's work.

The spec was later changed to "in response to an ICMP error packet." The world progressed, vendors made changes to their stacks allowing ICMP error messages in response to echo requests, and with the rise of firewalls and ACLs, stray UDP packets sometimes get blocked, but ICMP echo request could get through. Of course, your success on that today varies wildly. I would expect the tracert and other tools were written at a time when using ICMP echo responses wasn't so problematic.

These days you can't really say UDP is better than ICMP. Or that either of those is better than TCP. It completely depends on the path you are traversing and the security policies in place. You may need to try one, both, or all three implementations.

Sources:

http://ftp.arl.army.mil/~mike/ping.html http://www.inetdaemon.com/tutorials/troubleshooting/tools/traceroute/definition.shtml

Edit:

Changed RFC from IP (RFC791) to ICMP (RFC792) that says in the intro:

To avoid the infinite regress of messages about messages etc., no ICMP messages are sent about ICMP messages.

That's the bit that caused vendors to not send "Time Exceeded" errors for echo requests.

RFC1122, Requirements for Internet Hosts, in section 3.2.2. is the update that says hosts shouldn't respond to ICMP error messages.