From: Alex Henrie <alexhenrie24@gmail.com>
To: dan@danm.net, davem@davemloft.net, dsahern@kernel.org,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
bagasdotme@gmail.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, regressions@lists.linux.dev
Cc: Alex Henrie <alexhenrie24@gmail.com>
Subject: Re: [REGRESSION] net/ipv6/addrconf: Temporary addresses with short lifetimes generating when they shouldn't, causing applications to fail
Date: Fri, 22 Dec 2023 16:42:27 -0700 [thread overview]
Message-ID: <20231222234237.44823-1-alexhenrie24@gmail.com> (raw)
In-Reply-To: <20231221231115.12402-1-dan@danm.net>
On Thu, Dec 21, 2023 at 4:12 PM Dan Moulding <dan@danm.net> wrote:
>
> I started running v6.7-rc5 on a desktop and began having problems
> where Chromium would frequently fail to load pages and give an
> "ERR_NETWORK_CHANGED" message instead. I also noticed instability in
> avahi-daemon (it would stop resolving local names and/or consume 100%
> CPU). Eventually I discovered that what is happening is that new
> temporary IPv6 addresses for a ULA address are being generated once
> every second, with very short preferred lifetimes (and I had an
> interface with thousands of such temporary addresses). I also found
> that it seems to be triggered when one of the devices on the network
> sends a router advertisement with a prefix that has a preferred
> lifetime of 0 (presumably it's sending that because it wants to
> deprecate that prefix).
>
> I bisected it to commit 629df6701c8a ("net: ipv6/addrconf: clamp
> preferred_lft to the minimum required"). Upon reviewing that change, I
> see that it has changed when generation of temporary addresses will be
> allowed. I believe that change might have inadvertently caused the
> kernel to violate RFC 4941 and might need to be reverted.
>
> In particular RFC 4941 specifies that the preferred lifetime of a
> temporary address must not be greater than the preferred lifetime of
> the public address it is derived from. However, this change allows a
> temporary address to be generated with a preferred lifetime greater
> than the public address' preferred lifetime.
>
> From RFC 4941:
>
> 4. When creating a temporary address, the lifetime values MUST be
> derived from the corresponding prefix as follows:
>
> * Its Valid Lifetime is the lower of the Valid Lifetime of the
> public address or TEMP_VALID_LIFETIME.
>
> * Its Preferred Lifetime is the lower of the Preferred Lifetime
> of the public address or TEMP_PREFERRED_LIFETIME -
> DESYNC_FACTOR.
>
> Previously temporary addresses would not be generated for an interface
> if the administratively configured preferred lifetime on that
> interface was too short. This change tries to avoid that, and allow
> generating temporary addresses even on interfaces with very short
> configured lifetimes, by simply increasing the preferred lifetime of
> the generated address. However, doing so runs afoul of the above
> requirement. It allows the preferred lifetime of the temporary address
> to be increased to a value that is larger than the public address'
> preferred lifetime. For example, in my case where the router
> advertisement causes the public address' preferred lifetime to be set
> to 0, the current code allows a temporary address to be generated with
> a preferred lifetime of (regen_advance + age + 1), which is obviously
> greater than 0. It also, in my case, leads to new temporary addresses
> with very short lifetimes being generated, about once every second,
> leading to the application-level issues I described above.
Sorry for the unintended consequences, and thank you for the detailed
explanation. Does this patch fix the problem for you?
-Alex
Alex Henrie (1):
net: ipv6/addrconf: clamp prefered_lft to the public address preferred
lifetime
net/ipv6/addrconf.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
--
2.43.0
next prev parent reply other threads:[~2023-12-22 23:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-21 23:10 [REGRESSION] net/ipv6/addrconf: Temporary addresses with short lifetimes generating when they shouldn't, causing applications to fail Dan Moulding
2023-12-22 23:42 ` Alex Henrie [this message]
2023-12-22 23:42 ` [PATCH net] net: ipv6/addrconf: clamp temporary address's preferred lifetime to public address's Alex Henrie
2023-12-23 15:22 ` [REGRESSION] net/ipv6/addrconf: Temporary addresses with short lifetimes generating when they shouldn't, causing applications to fail Dan Moulding
2023-12-24 0:07 ` Alex Henrie
2023-12-29 16:33 ` Dan Moulding
2023-12-29 22:52 ` David Ahern
2023-12-30 4:32 ` [PATCH] Revert "net: ipv6/addrconf: clamp preferred_lft to the minimum required" Alex Henrie
2023-12-30 15:43 ` David Ahern
2024-01-02 23:10 ` patchwork-bot+netdevbpf
2023-12-30 4:12 ` [REGRESSION] net/ipv6/addrconf: Temporary addresses with short lifetimes generating when they shouldn't, causing applications to fail Alex Henrie
2023-12-23 8:42 ` Linux regression tracking #adding (Thorsten Leemhuis)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231222234237.44823-1-alexhenrie24@gmail.com \
--to=alexhenrie24@gmail.com \
--cc=bagasdotme@gmail.com \
--cc=dan@danm.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=regressions@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).