Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Tom Herbert <[e-mail]>]

On Thu, Jul 18, 2019 at 8:02 PM Joe Touch <[e-mail]> wrote:
>
>
>
> On Jul 18, 2019, at 7:02 PM, Tom Herbert <[e-mail]> wrote:
>
> Right, but this is UDP. There are inherent limits to what we can do here.
>
> IPv6 has HBH and dest options as TLVs. IPv6 allows unrecognized
> options. IPv6 has bits in the option type that tell receiver whether
> to drop packet if option is unknown. IPv6 is stateless and doesn't
> define any negotiation. The solution in IPv6 provides correctness for
> options that cannot safely be ingnored. Please explain EXACTLY why UDP
> options cannot use this same technique.
>
>
> Again, because this is UDP.
>
This is not UDP. UDP doesn't have options nor any sort of negotiation.
This is a new protocol.

> IPv6 doesn’t need to deal with legacy receivers that ignore all options anyway - all the time.
>
> So basically “drop if not supported” has no meaning ALREADY for legacy receivers. Anything further - deeper, or involving state - can still be performed by the receiver, at the receiver’s decision already anyway.

The legacy receiver problem is already resolved by putting options
that can't be ignored in packet with UDP length=8. The problem is when
a non-legacy receiver receives an options that it doesn't recognize.
If the option cannot be safely ignored that packet needs to be
dropped. This is the exact same problem that IPv6 has and hence the
same solution can be applied.

In any case, if you're saying we can't solve this problem and that the
protocol isn't extensible to something as simple as a stateless
compression option, then I raise that a major design flaw with the
protocol.

Tom

>
> Joe