Re: [PATCH v3] netlink: Return prefix length for IPv6 addresses in nl_addr_get()

[Jon Maloy <jmaloy@redhat.com>]

On 2026-03-09 05:56, Stefano Brivio wrote:
> The patch looks good to me now, but I have two questions:
> 
> On Sat,  7 Mar 2026 13:41:57 -0500
> Jon Maloy <jmaloy@redhat.com> wrote:
> 
>> nl_addr_get() was not setting the prefix_len output parameter for
>> IPv6 addresses, only for IPv4. This meant callers always got 0 for
>> IPv6, forcing them to use a hardcoded default (64).
>>
>> Fix by assigning *prefix_len even in the IPv6 case.
>>
>> We also add another functional change. We now check for if an AF_INET
>> address is link local, in which case we have to skip it.
> 
> The reason why the original code skipped IPv6 link-local addresses and
> not IPv4 link-local ones is that copying a IPv6 link-local address
> clearly makes no sense and breaks things.
> 
> For IPv4 I wasn't quite sure, and it seemed to work just like other
> addresses, so I never took care of excluding them.
> 
> I tend to think it's correct to exclude them, also for consistency with
> IPv6, but I'm not quite sure if we risk breaking something. I have some
> vague recollection of link-local addresses being used in some cloud
> (probably Google Computing Platform), at least for some Podman tests.
> I'll try to find some pointers to it.
> 
> Did you already look into the matter, though?

Honestly I though it was just an oversight.


> 
> By the way, this makes things inconsistent with nl_addr_dup() (used by
> the vast majority of users), where IPv4 link-local addresses are copied
> just like all the other ones.
> 
>> Although it
>> is conventional to set the scope of such addresses to RT_SCOPE_LINK,
> 
> You mean that users manually do that? I think it's kind of rare
> actually. Does the kernel do that? Or configuration agents such as
> NetworkManager? I wonder a bit what you consider as "user" here.

It is normally set by NetworkManager, but I don't think that means we
can trust it at 100%.
Anyway, I will remove this change in an update, as we agreed upon this
morning.

/jon

> 
>> this is not stated in any RFC, and we cannot trust it to have been set
>> correctly by the user, just as we cannot trust it to have been set
>> correctly for any other AF_INET address. We therefore add this check
>> explicitly on the address itself.
>