Iirc TC flag is "truncated content" but I need to look it up again; it’s been an eternity ( > 24 years :-) ).
Yes, I had forgotten about the possibility of using IP fragmentation. IPv6 has no fragmentation in middle boxes, only in the source, so it may not help you if you are a server and you send back more than 1280 bytes. So do you get IPv4 and IPv6 responses back IP-fragmented if they are between 1281 and 1500 bytes long?
Anyone any thoughts about the first question? If you only get a part of a response that is > 1280 or even >1500 bytes long, is a first-part any use to you, because you will be getting it again as the first part of a TCP connection, no? So why send that first part twice?
I read
RFC 5966 and noted that it points out the unreliability of relying on IP fragmentation in middle boxes, because of dodgy middle boxes and evil firewalls that don’t like reassembling fragments or can’t be bothered to wait the time required or tie up the RAM necessary; indeed if you are a firewall, allocing 64k of RAM for each flow in order to handle reassembly over a long time would introduce huge delays and be a method for a DOS attack by exhausting server RAM.
It talks about an IP SDU or is it PDU (?) size limit of 512 bytes but I ignored this when I first started this thread as I can’t see that it’s realistic for today’s systems and would think that surely <= 1280 bytes
PDU size is safe enough, no?
Just to check I have this correct you get 512 bytes - or maybe more, I don’t know - in a UDP packet and then when the TCP connection starts you get that same data repeated at the beginning.