Re: Non-Last Small IPv6 Fragments

["Bjoern A. Zeeb" <[e-mail]>]

On 13 Jan 2019, at 21:40, Brian E Carpenter wrote:

> On 2019-01-14 08:48, Tom Herbert wrote:
>> On Sun, Jan 13, 2019 at 11:25 AM Brian E Carpenter
>> <[e-mail]> wrote:
>>>
>>> On 2019-01-14 07:54, Bob Hinden wrote:
>>>> Unleveling a bit.
>>>>
>>>> I think the w.g. should be very cautious about making protocol 
>>>> changes based on what appears to be a fragmentation resource 
>>>> management problem in an implementation.
>>>
>>> I agree. However, I wonder if we need to clarify that there is no 
>>> rule that non-last fragments must be at least 1280. It seems that 
>>> the Linux patch assumed that there is
>>> such a rule.

I think if you want to clarify anything than it is “What does minimum 
MTU of 1280 mean?”  I would assume that’s where the problem comes 
from. To my best memory it’s formulated as loser text and not that 
formal (*)(**).   The misunderstanding that one needs to be able to send 
packets with up-to 1280 doesn’t mean that one has to send packets that 
big.

(*) and I seem to remember that I always have MTU vs. MRU on my mind 
when I read these paragraphs and think that’s conflated in the text.
(**) Also that section 4.5 and 5 contradict each other as section 4.5 
says “fragment when no fit into path’s MTU”, while section 5 says 
“you may fragment already for anything larger than 1280”, e.g., a 
path’s mtu of 1500 can sill fragment a 1432 octet packet.


> Well, I'm an advocate of one step at a time.
>
> Step 1: As an addendum to RFC8200, state that there is no rule that 
> non-last fragments must be at least 1280.

I am kind-of against this.  Just when we find any buggy implementation 
we cannot amend an RFC or any other document to clarify.  A bug is a bug 
and a OS vendor problem.  The document nowhere states what was 
implemented so why give them special treatment?

That’s a problem that community needs to solve and they’ll have good 
reference in public mailing list archives that what they did will break 
their communications and that’s it.


> Step 2: Discuss whether there *should* be any rules about non-last 
> fragment size, given that there are legitimate cases where they will 
> be less than 1280.
>
> Step 3: TBD

Now that’s a change to the current specification and that can be 
discussed but beware that changing current behaviour (and it was 
mentioned in this thread that there seem to be implementations of 
different sending behaviour) will mean that OS developers will have to 
carry “backward compatibility” for a long time (at least allowing 
the user to make a choice).

/bz