Re: [PATCH net-next 0/5] net: Extend address label support

[Petr Machata <petrm@nvidia.com>]

Jakub Kicinski <kuba@kernel.org> writes:

> On Mon, 13 Mar 2023 14:26:56 +0100 Petr Machata wrote:
>> > Feels a bit like we're missing motivation for this change.
>> > I thought address labels were legacy cruft.  
>> 
>> The immutability and lack of IPv6 support is seriously limiting, so the
>> fact nobody is using this is not that surprising.
>> 
>> > Also the usual concern about allowing to change things is that some
>> > user space will assume it's immutable. The label could until this 
>> > set be used as part of a stable key, right?  
>> 
>> Maybe. But to change a label, you need to be an admin, so yeah, you can
>> screw things up if you want to. You could e.g. delete the address
>> outright. In the end it should be on me as an admin to run a stack that
>> is not stumbling over itself.
>
> I haven't seen that caveat under the "no uAPI-visible regressions"
> rule book...  Have you done a github grep for uses of this attr?

I didn't realize this before, but the labels do change today as a result
of interface renames. That's... not good. One thing is an admin coming
along and changing a label, which yeah, would change a label. A change
in netdevice name screwing up all the labels is a whole different level.
I guess whatever the original use case for labels was leaks through too
much at this point.

So scratch all this.

I think we will have to use address protocol to do this. IPv6 protocol
already supports replace semantics. Any objections to adding the same
for IPv4?

Like with the labels, address replacement messages with an explicit
IFA_PROTO are not bounced, they just neglect to actually change the
protocol. But it makes no sense to me that someone would issue address
replacement with an explicit proto set which differs from the current
one, but would still rely on the fact that the proto doesn't change...