nanog mailing list archives

Re: Traceroute and random UDP ports


From: John Kristoff <jtk () centergate net>
Date: Wed, 13 Aug 2008 07:56:53 -0500

On Wed, 13 Aug 2008 05:24:17 +0530
"Glen Kent" <glen.kent () gmail com> wrote:

The outgoing packets from traceroute are sent towards the destination
using UDP and very high port numbers, typically in the range of 32,768
and higher. This is because no one is gernally expected to run UDP
services up there, so when the packet finally reaches the destination,
traceroute can tell that it got to the end (because the ICMP changes
from "TTL exceeded" to "port unreachable").

Yes, this is correct.  Note that this is all the case largely due to
historical artifact of how TCP/IP stacks at the time behaved.  For
example, UDP was chosen simply because some hosts took the notion of not
replying to ICMP error messages literally, making the use of an ICMP
traceroute tool early on unreliable.  This, I believe, is no longer the
primary problem now, filtering is.  This is often why a TCP-based
traceroute to port 80 is so useful these days.

My question is: What if the receiver is actually listening on one of
the "random" UDP ports? What would happen in such cases?

You probably won't get a response from that message.  Most UDP
listeners tend to be silent unless a well formed message arrives that
requires a response.  So it may look like you have reached the host for
at least that one traceroute packet.

Also, why do we increase the UDP port number with each subsequent
traceroute packet that is sent?

I don't know definitively, but I have an of educated guess  Since by
default the original traceroute tool sent three packets per TTL it
might not only increase likelihood of one getting through, but also the
likelihood of hitting a closed port.  For further information I
sugguest consulting Stevens TCP/IP Illustrated chapter 8, dated, but
still an indispensable resource.

John


Current thread: