RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt

[Sheng Jiang <[e-mail]>]

>Personally, I think the right solution is not to drop fragments, but impose
>limits on storage for reassembly. 

+1. Also some operation or implementation recommendations, which try to limit the usage of fragment in certain scenarios, may be helpful.

Sheng

>Fragments arriving in B should consume at
>most some amount of storage for some amount of time; if the time elapses,
>one discards the stale fragments, and if a new fragment arrives when
>resources are maxed out, one discards the oldest fragment present (LRU). We
>can argue ad infinitum on the amount of storage and time; I actually don't
>think the exact numbers are important. The time should be some multiple of
>the largest RTT the system sees, which is probably on the order of hundreds
>of milliseconds to seconds, and the storage quantum that is reasonable is
>probably measured in kilobytes. Beyond orders of magnitude, it's cook's
>choice.
>
>Listing the folks that have that firewall rule - I can't say. There seems to be a
>widely-held belief that the people exist.
>
>On Jun 25, 2013, at 11:56 AM, Ole Troan <[e-mail]> wrote:
>
>> Randy,
>>
>>>> If it's a statement of fact, it shouldn't use RFC 2119 language. It
>>>> should simply state the truth: "Network operators might filter IPv6
>>>> fragments."
>>>
>>> s/might/do/
>>
>> would you be able to answer why and where?
>>
>> cheers,
>> Ole
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[e-mail]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------