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

[Joe Touch <[e-mail]>]

> On Jan 5, 2020, at 1:17 PM, Tom Herbert <[e-mail]> wrote:
> 
>> 
>> You keep citing network protocols, not transport.
>> 
> Because, just like UDP, IPv6 is a stateless, connectionless, datagram
> protocol that works over unicast, multicast, anycast, and broadcast.

IPv6 is two things UDP is or should not be:

1. a network protocol, not a transport
	network protocols rely on ways to inform the intermediate hops
	transports can and should rely on the endpoints 

2. overbuilt
	if we learned anything with IPv6, it’s that adding the kitchen sink helps delay adoption

The lesson to follow here is TCP and TCP SYNs in particular. There is no TCP option that causes a received packet to be IGNORED (there could easily have been).

> They have all the same pertinent properties. If you know of a
> transport protocol with options having these same properties then we
> can look at that (note, that protocol is not TCP!).

It is TCP SYNs. They have to be interpreted without context.

> 
>> Transport protocols don’t have this behavior - and it’s IMPOSSIBLE to implement for legacy UDP receivers.
>> 
> It's not impossible, I've already suggested the necessary text and
> requirements to prevent a receiver from incorrectly processing an
> unknown options that cannot be ignored.

That code never affects legacy receivers.

> I claim that this protocol
> works for all use cases of UDP in order to satisfy the requirement the
> requirement. If you dispute this claim, then please provide the exact
> scenario where you think it fails.

First, it fails to be motivated by an example.

> Here again are the requirements to
> ensure:
> 
> "
> 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 rest of this is not a requirement, it’s an implementation...

> ...
> If an option that cannot be ignored is received by a node that does
> not recognize the option then the packet MUST be dropped.

Fail. That causes the same packet to be silently dropped by option-aware receivers and received as zero-length by legacy receivers.

That’s a non-starter. There is no justification for needing that behavior.

> 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.

This does NOT ensure that legacy receivers and option-aware function the same way. Legacy would receive zero-length packets. Option-aware should do the same.

>  - If an option is received with [he needed signal]

(again, the rest of this sentence is implementation, not requirement)

>  and the receiver does not recognize the option,
> then the packet MUST be dropped.

Same problem. Different behavior for legacy and option-aware.

Declaring that an option CANNOT BE IGNORED affects ONLY THAT OPTION. We can decide to make it trash all other options, but we can’t make it drop a packet as a whole.

Joe