Re: [tsvwg] Alternative version of the UDP FRAG option

[Joe Touch <[e-mail]>]

Frag+lite can still be checksummed after reassembly as is. We don’t want or need to do that check twice and can’t usefully string together partial sums. 

Joe

> On Mar 12, 2019, at 12:10 AM, C. M. Heard <[e-mail]> wrote:
> 
> On Mon, Mar 11, 2019 at 9:26 AM C. M. Heard <[e-mail]> wrote:
> > I'd like to float a different idea, namely, putting the UDP user data
> > inside the FRAG option itself.
> 
> Well, that proposal was rather obviously flawed by limiting fragment
> sizes to ~240 bytes. My apologies. I withdraw the FRAG proposal in
> 
> https://mailarchive.ietf.org/arch/msg/tsvwg/JZ8ohgwMs9eRPRQ6KJDqUZTJxSk
> 
> However, I think that the following simpler version will actually work:
> maintain the format of the FRAG option as currently defined, but instead
> of having the option capture preceding conventional or LITE user data as
> fragment data, insist that it appear ***last*** in the option list and
> have it capture all remaining octets in the packet as fragment data. By
> convention, if this option appears, OCS would cover all UDP options as
> well as all octets in the UDP trailer that follow the FRAG option.
> 
> The following requirements would apply:
> 
>    >> When the FRAG option appears, it MUST come last in the UDP options
>    list.  All remaining options in the packet are interpreted as fragment
>    data.
> 
>    >> OCS, if present, covers both the FRAG option and the trailing
>    fragment data.
> 
>    >> A host that wishes to signal that it is able to accept and process
>    the FRAG option MAY do so by transmitting an unfragmented datagram
>    with an empty terminal FRAG option whose Offset and Checksum fields
>    are set to zero.
> 
>    >> Non-empty FRAG options MUST NOT be present in packets with ordinary
>    UDP user data or LITE data. Any such options MUST be silently dropped.
> 
>    >> UDP options other than OCS and padding MUST NOT accompany the FRAG
>    option in non-terminal fragments.  Any such options MUST be silently
>    dropped.  All other options that apply to a reassembled packet must
>    accompany the FRAG header in the terminal fragment.
> 
> This proposal does not suffer from the disadvantage that a legacy receiver
> could misinterpret a UDP fragment as a complete datagram, as does the
> currently-defined version of FRAG without LITE.  And it avoids the problem
> that OCS does not cover the currently defined version of FRAG+LITE.
> 
> Note that because of their unusual property of capturing following or
> preceding data, FRAG and LITE would have to be mandatory to
> recognize, but I do not believe that they should be mandatory to
> generate or process. An implementation that cannot process these
> options should silently drop packets that contain them.
> 
> There's probably something wrong; if so, please tell me what it is.
> 
> Mike Heard