Message-ID: <20231222234237.44823-1-alexhenrie24@gmail.com>
Date: Fri, 22 Dec 2023 16:42:27 -0700
From: Alex Henrie <alexhenrie24@...il.com>
To: dan@...m.net,
	davem@...emloft.net,
	dsahern@...nel.org,
	edumazet@...gle.com,
	kuba@...nel.org,
	pabeni@...hat.com,
	bagasdotme@...il.com,
	netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	regressions@...ts.linux.dev
Cc: Alex Henrie <alexhenrie24@...il.com>
Subject: Re: [REGRESSION] net/ipv6/addrconf: Temporary addresses with short lifetimes generating when they shouldn't, causing applications to fail

On Thu, Dec 21, 2023 at 4:12 PM Dan Moulding <dan@...m.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

Powered by blists - more mailing lists