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.
The reason for that result on a trace is that, some ISP, does load balance in his Autonomus System, thats it: same destination across diferent ways.
This is the reason that you looks, in the same hop, ex: 4, 5 and 6, that one packet goes hrough every one of the links that can reach the destination.
Best Answer
As Ron said, this is a pretty simple thing to test - you should give it a try if you haven't already.
In BSD systems traceroute will use a range of high, unregistered UDP port numbers as well as TTL. The device originating the probes will send 3 probes, they will look like this:
NOTE: The port numbers won't necessarily be exact in your tests.
In the condition that the we're NOT tracerouting to the next-hop, you will see the following message from the next device:
Time to Live Exceeded
This is what we would expect, to see as traceroute progresses, the next device's probes would look like this:
Now let's say that second set of probes will reach our intended destination. The response we will get is (and this is a portion directly from tcpdump):
udp port 33437 unreachable
Now what does this mean? It means we've reached our destination, because only our destination can say "No this port is not available" (as we would expect from the higher unregistered UDP port range).
The cool thing about traceroute is that, it has no idea if you're trying to hit something 20 hops away, or just 1 hop away - it needs to be able to adapt to any of those situations.
So it will behave no differently than it would at the last hop in a 20 hop traceroute.
If you traceroute your next hop, your probes would look the same:
But the different here is, a TTL of 1 is enough to get to your next hop. So you would see the "udp port XXXXX unreachable" message right away, implying that the traceroute has completed. Instead of seeing the "Time to Live Exceeded" messages.
I hope this helps clear things up, if you have any other questions related to this - leave a comment and I'll be happy to update my answer.