5

Let's say someone sends a UDP packet, just like a traceroute implementations. The packet has a TTL of 1 in the IP header, causing the first router to discard it and generate an ICMP Time Exceeded reply to the sender.

Does the router have any guarantee that the sender receives the ICMP Time Exceeded error message it generated and sent?

Is ICMP implemented on top of UDP? Are there any error control mechanisms implemented as part of ICMP if so?

I want a pretty basic simple answer, I just thought I'd work the question a few ways so it would be more clear.

2 Answers 2

7

ICMP is not UDP, and it's actually not even IP. It's another OSI layer 3 protocol (network layer) alongside IP. That said, it has an IP compatible header at the beginning of a packet.

There is no guarantee that an ICMP packet will be delivered. It has the same delivery guarantees of any other packet on the internet: none. There are no attempts to ensure that it gets delivered, no retry mechanism, but there is a checksum in both the IP header and the ICMP header. A higher level protocol should retry sending the packet that generated the error, which will cause another Time Exceeded packet to be generated, and eventually one of these will be received by the sender.

http://www.networksorcery.com/enp/protocol/icmp.htm has an example ICMP header (encapsulated inside what is identical to an IP header) and information about the different types of ICMP messages.

Given that people are downvoting this post and misunderstanding, I'll clarify:

IP is the lingua franca of the internet. Packets are routed by their IP headers. Protocols are encapsulated within IP (TCP, UDP, SCTP, etc) for most application level communication.

How do you communicate when something goes wrong with IP layer communication? ICMP is used for this. Can you communicate IP layer errors in IP? It's a chicken and egg problem, and as indicated by RFCs, gets muddy. ICMP messages have an IP header, and an IP protocol is reserved for them, but ICMP is an IP layer protocol, not it is not encapsulated inside an IP packet. Therefore I consider it to be a protocol used alongside IP.

We can quibble all day long as to "whether ICMP is IP", but the most I'd concede is that yeah, it's IP, "sort of".

5
  • ICMP is indeed IP. It is IP protocol number 1 where as TCP is 6 and UDP is 17. The first paragraph of this answer is incorrect. Other paragraphs are correct.
    – snap
    Commented Aug 4, 2011 at 3:31
  • Also, TCP has delivery guarantees (as do some other IP protocols, I believe). That guarantee is: You will get confirmation of delivery of the packet you sent (or one indistinguishable from it), or the connection will fail / break. Commented Aug 4, 2011 at 3:45
  • TCP is not IP. TCP is a protocol layered on top of IP. ICMP is another layer 3 protocol - it's involved in error reporting at the IP layer, and thus cannot be IP. It's header is indistinguishable from an IP packet, and thus can be routed as IP.
    – akramer
    Commented Aug 4, 2011 at 3:56
  • Quoth RFC 792: ICMP, uses the basic support of IP as if it were a higher level protocol, however, ICMP is actually an integral part of IP, and must be implemented by every IP module.
    – akramer
    Commented Aug 4, 2011 at 4:17
  • 1
    @akramer, I see your point. I think we are splitting hairs here. We have a different viewpoint. I have a very practical point of view to things: when I look at a kernel source code, I can see that ICMP packet goes through ip_input() and ip_output(); when I configure a packet filter to filter by IP, it matches ICMP packets (e.g. "tcpdump ip"); when a (dumb) router forwards an ICMP packet not destined to itself, it just sees it as an IP packet and sends it onwards. From theoretical point of view it may be different, e.g. when trying to classify protocols in ISO/OSI layered hierarchy.
    – snap
    Commented Aug 4, 2011 at 6:45
3

ICMP is IP, not UDP, but you're right, it's unreliabable.

Here is a list of usages.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .