netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).