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

On Fri, Dec 17, 2021 at 06:55:43PM +0100, Toke Høiland-Jørgensen wrote:

quoted

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?

I don't know of any existing application that actually does. But it's
easy to imagine a developer setting only parts of the rtmsg structure
and leaving the rest uninitialised. Exposing the problem might not help
the end user, who may have no way to modify the broken program.

Also, for people using ifupdown (/etc/network/interfaces on Debian and
derivatives), rejecting a command can cancel the configuration of an
entire device section. So a stray tos option on an ip -6 route command
would now leave the network interface entirely unconfigured.

I'm not saying these situations exist, just trying to anticipate all
possible side effects.

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?

Given that it's something that'd be easy to revert, maybe we can try
this approach.

-Toke