Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

[Joe Touch <[e-mail]>]

I'm not sure whether noting the issue is critical or not, but tonly one 
of these examples is useful, IMO, as noted below:

On 10/25/2012 4:30 PM, Andrew Yourtchenko wrote:
...
> +1 on documenting, maybe worth adding to the section 2.2 a few more
> protocol case studies:
>
> http://www.ietf.org/mail-archive/web/ipsec/current/msg07749.html

This one seems useful to the point being discussed (of "drop all" 
fragment cases in the wild).

> http://www.ietf.org/proceedings/71/slides/radext-4.pdf

The above is more about trying to avoid fragmentation than any specific 
reason that fragmentation is a problem. Fragmentation is known to 
increase probability of drop (opportunity for reassembly overload, 
increased exposure to the impact of a packet drop). This example isn't 
directly about "drop all" cases, though.

> http://support.microsoft.com/kb/244474

>From that link:

"Because UDP is a connectionless protocol, fragmented UDP packets will 
be dropped if they arrive at the destination out of order. "

1) because UDP is connectionless, UDP packets should be tolerated out of 
order

2) fragments should already be tolerated out of order

So I can't understand why fragmented UDP packets should be dropped if 
they arrive out of order except as an implementation error.

Is this being noted as "bad advice arising from an implementation 
error"? If not, then it might not be useful to include.

> Alongside with that, also probably something like
> http://tools.ietf.org/html/rfc4347#section-4.2.3 could be also
> referenced as an example of application protocol's approach to
> fragmentation, alongside with
> http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-fragmentation-00,
> http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-03,
>
> This might help future app protocol writers' design choices, even if the
> document does not give the explicit advice (the fact on which I do not
> have an explicit opinion).

That advice presumes that the fragment size can be detected by the 
application; this is sometimes not the case. If such are being noted, 
the it might be useful to also at least recommend PLPMTUD (RFC 4821).

Joe