ICMP Destination Unreachable: too much data?

icmp
unreachable
retag add tags

Hi all!

I performed the following procedure:

Start the capture with WireShark.
Using a Python script, send a single UDP packet to my server, port 1235. The server is online but not listening on port 1235.
Stop the capture with WireShark.

As expected, in the capture I find two packets: the UDP packet I sent (coming from me) and an ICMP Destination Unreachable packet (coming from the server). Now, here is the Wikipedia page for the ICMP protocol. It says that a Destination Unreachable packet includes the original IP header and the first eight bytes of the IP payload (in the case of UDP, this amounts to only the UDP header).

However, the ICMP Destination Unreachable packet I find in my capture includes all the original UDP packet including, e.g., the data I sent. I wonder how is this possible? Which of the two following options is true?

The server actually sends back the entire packet, not stopping after the 8th byte of the IPdata.
WireShark does something under the hood which I am missing altogether?

I tried inspecting the raw bytes of the .pcap file generated when I save my capture, and indeed the payload of my original UDP message seems to appear only once. I don't know if this actually means something or not.

Matteo Monti

asked 2019-12-06 10:20:44 +0000

edit flag offensive 0 remove flag close merge delete

Comments

Here is the original UDP packet:

0000   00 08 e3 ff fc 04 a4 83 e7 33 51 c4 08 00 45 00   .........3Q...E.
0010   00 28 84 06 00 00 40 11 53 03 80 b3 b4 e0 34 30   .([email protected]
0020   39 f8 04 d2 04 d3 00 14 00 76 48 65 6c 6c 6f 20   9........vHello 
0030   57 6f 72 6c 64 21                                 World!

Here is the resulting ICMP packet

0000   a4 83 e7 33 51 c4 00 08 e3 ff fc 04 08 00 45 00   ...3Q.........E.
0010   00 44 a2 3f 00 00 27 01 4d be 34 30 39 f8 80 b3   .D.?..'.M.409...
0020   b4 e0 03 03 a0 de 00 00 00 00 45 00 00 28 84 06   ..........E..(..
0030   00 00 26 11 6d 03 80 b3 b4 e0 34 30 39 f8 04 ...

(more)

Matteo Monti (2019-12-06 10:25:18 +0000) edit

add a comment see more comments

1 Answer

Sort by

oldest

newest

most voted

Hmmm... interesting case. I just tested it with a couple of different IP destinations and some systems send inlcude the whole IP datagram in the ICMP destination unreachable response and some systems only included the first 64 bits of the original IP datagram (as RFC 792 is dictating).

So to answer your original question:

Which of the two following options is true?

The server actually sends back the entire packet, not stopping after the 8th byte of the IPdata.

WireShark does something under the hood which I am missing altogether?

Yes, "the server actually sends back the entire packet, not stopping after the 8th byte of the IPdata."

Why some systems do include the whole IP datagram instead of the first 64 bits is unknown to me.

18.5k

SYN-bit

answered 2019-12-06 12:54:25 +0000

edit flag offensive 0 remove flag delete link

Comments

RFC 4844 states:

In RFC 792, the "original datagram" field includes the IP header plus the next eight octets of the original datagram. RFC1812 extends the "original datagram" field to contain as many octets as possible without causing the ICMP message to exceed the minimum IPv4 reassembly buffer size (i.e., 576 octets).

However I can't find anything in RFC1812 that does extend the original datagram field.

grahamb (2019-12-06 13:11:15 +0000) edit

RFC1812

4.3.2.3 Original Message Header

   Historically, every ICMP error message has included the Internet
   header and at least the first 8 data bytes of the datagram that
   triggered the error.  This is no longer adequate, due to the use of
   IP-in-IP tunneling and other technologies.  Therefore, the ICMP
   datagram SHOULD contain as much of the original datagram as possible
   without the length of the ICMP datagram exceeding 576 bytes.  The
   returned IP header (and user data) MUST be identical to that which
   was received, except that the router is not required to undo any
   modifications to the IP header that are normally performed in
   forwarding that were performed before the error was detected (e.g.,
   decrementing the TTL, or updating options).  Note that the
   requirements of Section [4.3.3.5] supersede this requirement in some
   cases (i.e., for a Parameter Problem message, if the problem ...

(more)

Chuckc (2019-12-06 13:19:41 +0000) edit

Ah, 1812 calls it "Original Message Header". Inconsistent terminology :-)

grahamb (2019-12-06 13:29:34 +0000) edit

Thanks for the RFC references guys, I was too busy (or Lazy) today to search for it myself :-)

SYN-bit (2019-12-07 00:12:25 +0000) edit

I got lucky that "576" popped up in one of my query results and that made it easier to find the info in the RFC.

Chuckc (2019-12-07 03:53:14 +0000) edit

add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer

ICMP Destination Unreachable: too much data? edit

Comments

1 Answer

Comments