Again: I will be blunt, solely to get around long-standing lack of
communication.  Apologies in advance for bluntness, even though its
with good intentions.

>        have you experienced the scenario in reality, ever?


You mean as opposed to *actual* threats to linear IP ids, which
AFAIK nobody has yet cited in this discussion?

(Sorry. that was a low blow, but you really asked for it).


Yes of *course* I have seen it. (are you really that ill-informed
about IPv4?) Its well-known in certain circles that in Linux circa RH
7.3, some NICs will repeatedly lose fragments from outbound NFS write
RPC before the fragments ever hit the wire. The remaining fragments then
sit in reassembly buffers for at least their remaining TTL.
Which is typically around 63 seconds, these days.

Several Unix vendors have since shipped better-tuned reassembly
buffer management (if I wasn't bogged down with this, I'd be cleaning
up my own version for a commit.)

[Snip a not-relevant quote from RFC971]

I really don't understand why you are quoting RFC-791's paragraph
about "time to live" to yourself, nor why you do so without
attribution. The section relevant to this discussion is
"Fragmentation" and "An Example Reassembly Procedure", its description
of how the effetive reassembly timer should be set to no less than the
TTL in arriving fragments. Followed by a perusal of
sys/netinet/ip_input.c, particularly how the reassembly code hangs
onto fragments until their TTL hits zero.

The more we go into this, the more it seems to me that you could
(genuinely, and with no ill-will) use a lesson or two on IP
fragmentation and reassembly.  If that is the case, do you *really*
think you should be making technical decisions which so deeply impact
IP reassembly?