Re: [PATCH net-next 0/4] inet: Separate DSCP from ECN bits using new dscp_t type

quoted

quoted

Note that there's no equivalent of patch 3 for IPv6 (ip route), since
the tos/dsfield option is silently ignored for IPv6 routes.

Shouldn't we just start rejecting them, like for v4?

I had some thoughs about that, but didn't talk about them in the cover
letter since I felt there was already enough edge cases to discuss, and
this one wasn't directly related to this series (the problem is there
regardless of this RFC).

So, on the one hand, we have this old policy of ignoring unknown
netlink attributes, so it looks consistent to also ignore unused
structure fields.

On the other hand, ignoring rtm_tos leads to a different behaviour than
what was requested. So it certainly makes sense to at least warn the
user. But a hard fail may break existing programs that don't clear
rtm_tos by mistake.

I'm not too sure which approach is better.

So I guess you could argue that those applications were broken in the
first place, and so an explicit reject would only expose this? Do you
know of any applications that actually *function* while doing what you
describe?

One thought could be to add the rejection but be prepared to back it out
if it does turn out (during the -rc phase) that it breaks something?

-Toke