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

["C. M. Heard" <[e-mail]>]

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