Re: [tsvwg] Rregarding soft-state and UDP options

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

On Thu, Jan 2, 2020 at 6:23 PM Joe Touch wrote:

> On Jan 2, 2020, at 6:03 PM, Tom Herbert wrote:
> > IPv6 options
> > solve this problem by the "drop if unrecognized" bit so no negotiation
> > is ever necessary.
>
> That is ONE way to solve things, but its hardly “solved" when nearly
> nobody uses it.
>
> But it’s also not relevant here because IPv6 baked that rule in from the
> start. We can’t - there’s NOTHING we can do to make a legacy receiver drop
> packets with unknown options, regardless of the flags per se. All we can do
> is design them so the options and data are invisible together, which
> LITE+FRAG already supports.
>

Joe, I think that you are missing an important point here, namely that
the "drop
if unrecognized" flag (or Option Kind encoding rule) is proposed for the
benefit of ***option aware*** receivers, not for the benefit of legacy
receivers. As I stated in the message that started this thread (
https://mailarchive.ietf.org/arch/msg/tsvwg/qUtvvq78nnrizdxZmBuXUuVqPDI):

"Note that (c) is needed to ensure that user data accompanied by
an option that affect its processing is not delivered to an option-aware
receiver that does not recognize the option. As an example, AE
(Authentication and Encryption), as defined in the current spec, affects
the processing of the user data, but an implementation is not required
to support it. More generally, if an option that affects data
handling (such as compression) is defined in the future, option-aware
receivers that implement the current spec won't recognize it. They need
a means to determine whether it's safe to ignore the option and deliver
the user data or whether to discard both the data and the option."

I don't disagree that some sort of option negotiation and soft state is a
necessity, but I do not think that it covers all of the bases, particularly
since (as you note) the state is necessarily soft. It definitely can't
cover unidirectional transfers.

I do agree in principle that use of FRAG+LITE (in a form that includes OCS
over the entire surplus area) plus post-reassembly options addresses (a)
and (b) of my message (though I still reserve the right to comment when I
see the details).

Thanks,

Mike Heard