Re: [PATCH net v3] ipv6: reject wrapped temporary address preferred lifetimes

[Alex Henrie]

On Sat, Oct 31, 2026 at 5:44 AM Xia Yan <yanxia@xxxxxxxxxxxxxxxxxxxx> wrote:

> One question on the clamp added by f4bcbf360ac8, separate from the
> wrap fixed here - I don't think this patch needs to address it. I have
> only followed the source and have not run this case.
>
> As far as I can tell the clamp's termination relies on cfg.valid_lft
> and if_public_preferred_lft being finite. Consider a public address
> with both lifetimes at INFINITY_LIFETIME and a large regen_advance,
> with no wrap involved. For example with regen_min_advance=2,
> regen_max_retry=3, dad_transmits=1, an RA Retrans Timer around
> 28,600,000 ms and HZ=1000, regen_advance is around 85802; raising
> regen_max_retry via sysctl has the same effect.
>
> If temp_prefered_lft is set below regen_advance, the effective
> max_desync_factor goes negative, desync_factor is reset to 0, and the
> clamp engages on every creation. The clamped preferred lifetime
> regen_advance + age + 1 then passes all three checks, including the
> new one. But the temporary address inherits the public address's
> tstamp, so addrconf_verify_rtnl() finds it due for regeneration one
> second after each creation: one new temporary address per second,
> each living about temp_valid_lft. Creation is only refused once age
> grows enough that regen_advance + age + 1 exceeds cfg.valid_lft,
> which here is just temp_valid_lft, so the accumulation is bounded,
> but with the numbers above it can still reach tens of thousands of
> addresses.
>
> Is this finite-lifetime assumption part of the intended behavior of
> the clamp, or would it be worth tightening separately?

Hello Xia, that is a good question. In that extreme scenario, creating
one temporary address per second is intentional. As you noted,
regen_advance is not a constant. Before I added the clamp, Linux would
just stop creating temporary addresses if regen_advance increased to a
value larger than the preferred lifetime that the user specified. No
new addresses were created until the network interface was restarted,
even if later on regen_advance dropped to below the user's preferred
lifetime. Temporary address generation was effectively disabled,
eliminating the privacy protections that the user thought that they
had enabled.

When I wrote the patch, I did not consider that the temporary
addresses might be based on a static address that has an infinite
lifetime. If having a static address causes Linux to refuse to create
more temporary addresses after a certain period of time, that's a bug.
However, I have not been able to reproduce the problem: On my machine,
with a static address, max_desync_factor=10, temp_prefered_lft=30,
regen_min_advance=60, and temp_valid_lft=90, Linux 7.2 never stops
creating new temporary addresses. Is there another combination of
parameters that might cause a problem?

-Alex