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

[Alex Henrie]

On Mon, Nov 2, 2026 at 12:51 AM Xia Yan <yanxia@xxxxxxxxxxxxxxxxxxxx> wrote:

> The remaining worry for me is retention. With a short preferred
> lifetime and temp_valid_lft at its two-day default, deprecated
> temporary addresses stay on the interface until their valid lifetime
> expires, and this path does not check max_addresses. Your 90-second
> configuration ages them out fast; with the default I would expect
> many more addresses held at once, but I have not tested that or
> measured the cost. The creation rate also depends on DAD timing, so
> my earlier one-address-per-second estimate was too definite.

With the default temp_valid_lft of 2 days, creating 1 temporary
address per second would result in a maximum of 172,800 temporary
addresses. If the user explicitly sets temp_prefered_lft=1,
regen_min_advance=0, and dad_transmits=0, that's exactly what should
happen. When I tested that scenario on my desktop computer today,
Firefox worked and overall system stability was fine, but Chromium
failed to load any pages and NetworkManager became unresponsive. It
seems that some software doesn't mind that there are tens of thousands
of IPv6 addresses and other software won't tolerate it.

I'm not convinced that using max_addresses to limit the number of
temporary addresses is a good idea. The default value of max_addresses
is 16, so in the worst-case scenario, after 16 seconds temporary
address creation would be effectively disabled until the addresses
expire 2 days later. Similarly, if the user sets temp_prefered_lft to
1 hour (a perfectly reasonable value), the limit would be silently
reached after 16 hours. If we increase max_addresses to 48 to be sure
that 1 temporary address per hour can be created for 2 days, a brief
period of worst-case router advertisements would still use up all of
the addresses in 48 seconds. To protect the user's privacy, new
temporary addresses must continue to be created no matter what is
happening on the network. (With one exception: If the SLAAC address's
lifetime is so short that it's effectively a temporary address
already.)

We already have regen_min_advance which specifies the lower limit of
regen_advance. Maybe we should also have a regen_max_advance to
specify an upper limit. That way, a misconfigured router could not
cause a Linux client to create a new temporary address long before the
current temporary address expires, nor could a misconfigured router
cause Linux to use a long-lived SLAAC address without creating any
temporary addresses at all. The maximum number of simultaneous
temporary addresses would become temp_valid_lft / (temp_prefered_lft -
max_desync_factor - regen_max_advance), and the user would be expected
to set temp_prefered_lft to a value larger than max_desync_factor +
regen_max_advance. With temp_valid_lft=172800 (2 days),
temp_prefered_lft=3600 (1 hour), max_desync_factor=600 (10 minutes),
and regen_max_advance=300 (5 minutes), there would be a maximum of 64
temporary addresses at any given time.

-Alex