Strange IP flags MF and DF

edit

@André I tend to disagree on your interpretation of RFC 791. It states:

An internet datagram can be marked "don't fragment." Any internet datagram so marked is not to be internet fragmented under any circumstances. If internet datagram marked don't fragment cannot be delivered to its destination without fragmenting it, it is to be discarded instead.

It states that an internet datagram can be marked "don't fragment" not that a fragment can me marked "don't fragment". And this makes sense from the programmatically point of view. It is the application that marks a block of data it gives to the IP layer "don't fragment", it has no control over initial fragmentation.

It would be interesting to see how the IP datagram got fragmented on the path from sender to receiver. @BigFatCat, are you able to make traces along the path?

@SYN-bit: That was my conclusion as well

@SYN-bit@Christian_R RFC 791 also states:

To fragment a long internet datagram, an internet protocol module (for example, in a gateway), creates two new internet datagrams and copies the contents of the internet header fields from the long datagram into both new internet headers.

These new internet datagrams can be processed independently, regardless of the original datagram size.

I have seen firewalls setting DF flag on all outgoing traffic (fragments can be used as an attack vector). Probably something similar happened in this case. I don't see how an original sender could generate this flag combination; that doesn't make sense.

@André Interesting, devices that set DF flags on all traffic. I would say it's none of their business to do so, but then again, there are many implementations. You are right in that these packets might be generated by such devices. Hence my remark of doing captures along the path to see where the DF bit got set.

I am trying to determine where the packet is being fragmented. There appears to be stateful firewall somewhere because the TCP SYNC mss is 1460, but I am seeing the fragment packets with TCP segments of 1508. Another strange thing with the fragmented packets is the protocol number (06) is in the last fragment. I am used to seeing the protocol number in the first fragment.