ICMP Reliability

icmpnetwork-protocols

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.

Best Answer

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".

Related Solutions

Cisco – Generating ICMP packets when TTL=2

http://packetlife.net/blog/2008/dec/22/disabling-mpls-ttl-propagation/

http://www.ciscopress.com/articles/article.asp?p=680824&seqNum=4

Your packets are MPLS-encapsulated when the outer label's TTL is decremented to 0, but the inner packet TTL is not updated, so the TTL-expired labeled packet is forwarded on and the internal IP packet (with an apparently valid TTL) is returned to you as expired by the final MPLS router.

============================

When a labeled packet TTL expires the packet is actually forwarded on until the end of the 'tunnel' it's on, since the router that decremented the TTL field to 0 might not have a valid route back to the original sender. So the MPLS label is edited to indicate TTL expiration and eventually the final tunnel router decapsulates the 'valid but label-expired' packet and sends it back with a TTL failure message.

Disclaimer: I read through TTL-relevant sections of several RFC's but nothing was definite on this handling, so I would say that this behavior could vary from vendor to vendor.

Evidence from a captured packet:

Internet Control Message Protocol
Type: 11 (Time-to-live exceeded)
Code: 0 (Time to live exceeded in transit)
Checksum: 0xf4df [correct]
Internet Protocol, Src: 192.168.1.x (192.168.1.x), Dst: 8.8.8.8 (8.8.8.8)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x80 (DSCP 0x20: Class Selector 4; ECN: 0x00)
    Total Length: 92
    Identification: 0x6b56 (27478)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 2  <===== payload of packet entering MPLS tunnel
    Protocol: ICMP (1)
    Header checksum: 0x7abb [correct]
    Source: 192.168.1.x (192.168.1.x)
    Destination: 8.8.8.8 (8.8.8.8)
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0xf78f [correct]
    Identifier: 0x0001
    Sequence number: 111 (0x006f)
    Sequence number (LE): 28416 (0x6f00)
    Data (64 bytes)
MPLS Extensions
    Version: 2
    Reserved: 0x000
    Checksum: 0x5581 [correct]
    MPLS Stack Entry
        Length: 0x0008
        Class: 1
        C-Type: 1
        Label: 1864, Exp: 4, S: 1, TTL: 1
            0000 0000 0111 0100 1000 .... = Label: 1864
            .... .... .... .... .... 100. = Experimental: 4
            .... .... .... .... .... ...1 = Stack bit: Set
            Time to live: 1    <========== MPLS TTL

Traceroute, ICMP, UDP and TCP

ICMP messages are still IP packets. Traceroute uses ECHO Request (ICMP type 8) by default on Unix and Windows with incrementing TTLs, logging the sending address of each Time Exceeded (Type 11) message it gets back from the hops along the route. (cf: http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol)

This is the 'correct' way to do it, but you can run in to problems if some of the systems on the route drop or differently handle ICMP traffic.

Some implementations of traceroute (on Linux for example) have -T and -U options for switching to TCP/UDP instead (and a following -p argument to specify a destination port). This is useful for more closely simulating real traffic, which might get you a more accurate result in some cases.

I suspect the OSX implementation defaults to UDP for that reason, but I can't say for sure. You might find a switch to use ICMP instead.

Best Answer

Related Solutions

Cisco – Generating ICMP packets when TTL=2

Traceroute, ICMP, UDP and TCP

Related Topic