Traceroute and random UDP ports

Wed Aug 13 12:56:53 UTC 2008

On Wed, 13 Aug 2008 05:24:17 +0530
"Glen Kent" <glen.kent at 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