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

[Tom Herbert <[e-mail]>]

On Thu, Jan 2, 2020 at 8:21 PM Joe Touch <[e-mail]> wrote:
>
>
>
> On Jan 2, 2020, at 7:00 PM, C. M. Heard <[e-mail]> wrote:
>
> 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.
>
>
> FRAG+LITE already provides the behavior you want. The flag option fails to provide correct behavior for unidirectional or failed soft-state receivers - both of which are non-starters. A key requirement is that legacy receivers can silently ignore all options.

Here is the necessary requirements and text:

"
Options that cannot be ignored by a receiver due to side effects or
other requirements MAY be sent. An option that cannot be ignored is
indicated by the high order of the option type being set to 1 (if the
high order bit of the option type is 0 then the option can be safely
ignored).

If an option that cannot be ignored is received by a node that does
not recognize the option then the packet MUST be dropped. The
following requirements ensure this:

  - Options that cannot be ignored MUST NOT be sent in packets that do
not use FRAG+LITE format. This prevents a legacy receiver from
incorrectly ignoring an unknown option.
  - If an option is received with the high order bit of the bit of the
option type set to 1 and the receiver does not recognize the option,
then the packet MUST be dropped. This covers the case where a receiver
that processes UDP options however doesn't support a particular
received option that cannot be ignored.
"

This requirements yield a correct protocol for ALL CASES including
unidirectional, failed soft-state receivers, multicast, NAT
transitions, anycast, and simple unicast.

Tom

>
> …
>
> 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).
>
>
> AOK. And point taken that the soft state section needs clarification.
>
> Joe