“Fragmentation allowed” spotted by coincidence
A normal day
Today I wanted to investigate a phenomen with the Wireshark 2.0rc1 at MacOSX. For that kind of reason I started a local trace on my MacOS.
So I did not expect to see any strange traffic due to the point of tracing.
But in fact I saw more strange things than I had expected.
I saw some fragmented IP packets. Regarding to the my article about the IP-ID this should normally not happen, because the Path MTU Discovery should be activated everywhere in my network. But in fact I never had done an investigation for that kind.
As I looked a little bit closer I saw that mostly the multicast traffic has been affected.
Could that really be, that it is not allowed to use DNF Bit with multicast traffic??? It could be possible, because all is donne at the layer 3.
So I looked into the following RFCs:
- RFC 1191: Path MTU Discovery
- RFC 4821: Packetization Layer Path MTU Discovery
- RFC 1981: Path MTU Discovery for IP version 6
The RFC 1191 tells nothing about multicast, the RFC 4821 tells us at least that it is possible and only the RFC 1981 tells us that PathMTUdiscovery and multicasts can be used together at least with IPv6.
Path MTU Discovery supports multicast as well as unicast
destinations. In the case of a multicast destination, copies of a
packet may traverse many different paths to many different nodes.
Each path may have a different PMTU, and a single multicast packet
may result in multiple Packet Too Big messages, each reporting a
different next-hop MTU. The minimum PMTU value across the set of
paths in use determines the size of subsequent packets sent to the
That all hadn´t helped me with my actual finding.
Is there a motivation for that?
But of course the thing with the DF Bit it is not as bad as I first thought to myself.
From my point of view it makes sense, because multicast is often used by realtime protocols (e.g. IPTV).
And some other important aplications are also do set the DF Bit also to fragmentation allowed for example DNS.
I have posted in the next poicture a few examples ( The colored packest are allowed to be fragmented)
So maybe it is better to fragment a packet or a few, instead of the risk of gaps due to retransmissions for all devices.
I have seen this at least on MacOS X 10.10 and some other devices like Win 8.1.
Further I think I have seen it before at the nestat statistics, because I have wondered me a few times, why there some reassembled packets in the statistics of the
netstat -s display.
An other point could be that it is not wanted to have a more than one packet of the “Packet Too Big” message. So if the packet is too big for specific connection then fragmentation will be o.k.
That are just my assumings at this moment. I haven´t found any reliable, so far.
Personal I don´t have any problems with this behaviour, I think it is a legal way to deal with this.
But I haven´t seen this fact before. So my questions to are now teh follwings:
- “Does anybody know if and how I can tune this feature at the different Operating Systems?”
- “Does anybody know an reliable motivation for this or where can read further about it?”
- “Has anybody spotted some negativ side effects due to this behaviour?”
Please let me and the other readers know, if you have some answers at one or more of these questions?
PathMTU Discovery standardized technique for determining the maximum transmission unit (MTU) DNS Domanin name Service Multicast one-to-many or many-to-many distribution[ IPv6 Internet Protocol Version 6 MTU Maximum Transmission Unit ICMP Internet Control Message Protocol
Pingback: The relationship between the Maximum Transmission Unit (MTU) and the Maximum Segment Size (MSS) | CRnetPACKETS