Re: [REGRESSION] net/ipv6/addrconf: Temporary addresses with short lifetimes generating when they shouldn't, causing applications to fail

From: Alex Henrie
Date: Sat Dec 23 2023 - 19:08:14 EST


On Sat, Dec 23, 2023 at 8:22 AM Dan Moulding <dan@xxxxxxxx> wrote:
>
> > Sorry for the unintended consequences, and thank you for the detailed
> > explanation. Does this patch fix the problem for you?
>
> Thanks. I think this patch may resolve the application-level issues
> I'm seeing.
>
> However, it looks to me like this would still violate the RFC. The
> temoporary address' preferred liftime must be lower than /both/ the
> preferred lifetime of the public address and TEMP_PREFERRED_LIFETIME -
> DESYNC_FACTOR.
>
> These two existing lines ensure that it will meet the requirement:
>
> cfg.preferred_lft = cnf_temp_preferred_lft + age - idev->desync_factor;
> cfg.preferred_lft = min_t(__u32, ifp->prefered_lft, cfg.preferred_lft);
>
> Once that has been computed, cfg.preferred_lft is already at its
> maximum allowed value. There is no case where the RFC allows
> increasing that value after doing that computation.

TEMP_PREFERRED_LIFETIME is an administratively set variable: The user
can change it to whatever they want whenever they want, and the
operating system can adjust it automatically too. It might be more
clear to increase cnf_temp_preferred_lft before those two lines, but
the effect is the same as increasing cfg.preferred_lft afterwards.
Unless there's something else I'm missing, I don't see how this
approach could violate the RFC.

> I think the safest thing to do is revert this change, and try to find
> some other way to achieve the goal of preventing the user from
> administratively setting a preferred lifetime that prevents temporary
> addresses from being generated, when the user wants to use the privacy
> extensions. For example, this could be done where administratively
> configured values are accepted (wherever that is), and either generate
> a warning or reject the change, if the value provided by the user is
> lower than REGEN_ADVANCE.

It's fine to revert the commit for version 6.7 (after all, I think
everyone wants a break for the holidays). Hopefully by version 6.8 we
can agree on a way to support users who want to randomize their IPv6
address as frequently as the network allows.

-Alex