Re: Non-Last Small IPv6 Fragments

[Mark Smith <[e-mail]>]

On Mon., 14 Jan. 2019, 16:19 Erik Kline <[e-mail] wrote:

>
>> > Ole Troan wrote on 13/01/2019 20:03:
>> >> Let’s fix path MTU discovery. There’s no fix for fragmentation.
>> >
>> > pmtu discovery is hard because it needs a way for an intermediate node
>> to be able to signal a transmitting node to dynamically drop the MTU if
>> network conditions change.  The only way to reliably work around this is to
>> transmit at 1280 and claim implementation / operational breakage if this
>> cannot get through.  This, however, robs the host devices of the ability to
>> use higher MTUs.
>>
>> “Fix” as in something different than rfc8201.
>>
>
> How about a version of the fragment header that:
>
>     (a) *always* has the L4 header (or a configurable number of bytes) in
> every non-first fragment
>
> This could be documented on a per-L4+ basis how much needs to be included,
> i.e. we could have one doc for UDP and (say) a separate doc for information
> QUIC would need on a per-fragment basis.
>


"Transport Options for UDP"

https://tools.ietf.org/id/draft-ietf-tsvwg-udp-options-05.txt


"5.6. Maximum Segment Size (MSS)...............................13
      5.7. Fragmentation (FRAG).....................................14"



> This increases the overhead in a given fragment, but also helps to ensure
> that (eventually) intermediate systems can examine this field and
> preemptively make a drop/no-drop decision.
>
>     (b) state clearly that every non-last packet must contain
> $CONSENSUS_MINIMUM_BYTES of actual fragment payload
>
> No opinion on the exact value.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>