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