On Mon, Mar 09, 2026 at 02:04:40PM -0400, Jon Maloy wrote:
> 
> 
> 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,

Or, presumably by ip(8).

> but I don't think that means we
> can trust it at 100%.

Actually, I think this means we should trust it more.  I'd see this as
an explicit indication that regardless of any normal conventions, it's
being treated as a link-local address in the configuration of this
specific host, so we should too.

That's moot for the current patch, based on our earlier discussions,
but I think it's a relevant point for what we do in future.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson