3

I'm seeing an ICMP storm from a mobile phone netblocks belonging to "TELEFONICA MOVILES". Periodically we will get upwards of 5 million in a few seconds, all something like this:

08:12:05.740781 IP (tos 0x0, ttl 112, id 40224, offset 0, flags [none], proto ICMP (1), length 56) 200.76.88.6 > A.B.C.D: ICMP 200.39.21.96 unreachable - need to frag (mtu 250), length 36

("A.B.C.D" is my ip)

Is an mtu of 250 even possible or legal? 68? These ICMPs are connected with larger problems on our end, but I can't tell if they're a symptom, cause or just coincidence.

What does the path MTU discovery algorithm do in this case? The server is FreeBSD 7.

2 Answers 2

2

An MTU of 68 bytes is valid in IPv4 according to RFC 791:

Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets.

The requirement for the reassembled size to be supported is a lot larger:

Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled.

In IPv6 these numbers were increased to 1280 and 1500 bytes as mentioned in RFC 2460:

IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.

A node must be able to accept a fragmented packet that, after reassembly, is as large as 1500 octets. A node is permitted to accept fragmented packets that reassemble to more than 1500 octets. An upper-layer protocol or application that depends on IPv6 fragmentation to send packets larger than the MTU of a path should not send packets larger than 1500 octets unless it has assurance that the destination is capable of reassembling packets of that larger size.

3
  • The 1500 byte threshold is one of the few design choices in IPv6 I cannot find any rational explanation for. To me it would have seemed much more rational to let the threshold be equivalent to the maximum size that could be achieved with two 1280 byte fragments, which comes out as 2504 bytes. But I think most IPv6 implementations do support more than the 1500 bytes they are required to support.
    – kasperd
    Jan 14, 2016 at 16:56
  • I wonder if it was meant as a hint to higher level protocol designers that they really should avoid designing in fixed size packets that will nearly always need to be fragmented. Jan 15, 2016 at 14:26
  • @PeterGreen I don't think so. There are many links which use some other protocol somewhere between IPv6 and Ethernet and consequently have an MTU lower than 1500 bytes. In practice that means a 1500 bytes packet send over IPv6 will often need to be fragmented. So in that respect a 1500 bytes packet is almost as problematic as a 2504 bytes packet.
    – kasperd
    Jan 15, 2016 at 16:15
1

In case anyone cares, here's what I found.

Short answer is that no, these small MTUs are not legal but FreeBSD 7 & 8 should handle the situation better since some code changes were committed around the end of August.

This problem report has more: http://www.freebsd.org/cgi/query-pr.cgi?pr=146628

Path MTU discovery was not clearing the "don't fragment" flag, which means that a stubborn bad-behaving host on the other side would continue to send the storms of unreachable "frag needed" messages. Now after the first tiny MTU is received DF is cleared, which effectively moves the problem downstream to the router nearest the offender. (Since they will have to make absurd fragments for the offender.)

You must log in to answer this question.

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