For what purpose would one wish to send traceroute over TCP rather than UDP? What advantages/disadvantages are there in doing so? I know that traceroute normally uses UDP ICMP "echo" packets while traceroute with TCP uses "SYN" packets from its 3-way handshake, but I'm curious as to why one might be better than the other. If it depends on the situation, then what are those situations?
Tcp – Traceroute Over TCP vs UDP
icmptcptracerouteudp
Related Solutions
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.
Traceroute (the technique) technically doesn't rely on ICMP echo requests but rather a type of ICMP unreachable. The idea is that the host sends a packet with a low TTL value and then more with successively higher values. As these packets are dropped by the various routers in the path a TTL exceeded / unreachable message is sent back. The source of this message is then added to the list of hosts in the path.
As for the packet the host sends in the first place? That can vary, but to give you an idea the standard Linux traceroute command uses UDP. I believe the Microsoft tracert command uses an ICMP echo, though.
Best Answer
There's no such thing as "UDP ICMP "echo"". traceroute sends a UDP probe with an increasing TTL. That probe is a single datagram destined for a high port which is unlikely to be a listening service. As the datagram flows out across the network, the TTL decrements until it hits zero at which point an ICMP ERROR ("time exceeded") is generated. That ICMP message identifies a "hop". When the TTL is enough to reach the target, as there's no listener on that port, an ICMP "port unreachable" error is generated, thus ending the trace.
The purpose of
tcptracerouteis to do the same sort of path check with a TCP connection. It is most useful in diagnosing connection issues to a specific service. (eg. a web server) As the probes look like a normal TCP connection attempt, they'll go through NAT, firewalls, ACLs, rate-limits, etc. exactly as a connection from the intended application.