Received-SPF: pass (google.com: domain of linux-kernel+bounces-10479-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: Dan Moulding <dan@danm.net>
To: alexhenrie24@gmail.com
Cc: bagasdotme@gmail.com,
	dan@danm.net,
	davem@davemloft.net,
	dsahern@kernel.org,
	edumazet@google.com,
	kuba@kernel.org,
	linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org,
	pabeni@redhat.com,
	regressions@lists.linux.dev
Subject: Re: [REGRESSION] net/ipv6/addrconf: Temporary addresses with short lifetimes generating when they shouldn't, causing applications to fail
Date: Sat, 23 Dec 2023 08:22:35 -0700
Message-ID: <20231223152235.15713-1-dan@danm.net>
In-Reply-To: <20231222234237.44823-1-alexhenrie24@gmail.com>
References: <20231222234237.44823-1-alexhenrie24@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

> Sorry for the unintended consequences, and thank you for the detailed
> explanation. Does this patch fix the problem for you?

Thanks. I think this patch may resolve the application-level issues
I'm seeing.

However, it looks to me like this would still violate the RFC. The
temoporary address' preferred liftime must be lower than /both/ the
preferred lifetime of the public address and TEMP_PREFERRED_LIFETIME -
DESYNC_FACTOR.

These two existing lines ensure that it will meet the requirement:

	cfg.preferred_lft = cnf_temp_preferred_lft + age - idev->desync_factor;
	cfg.preferred_lft = min_t(__u32, ifp->prefered_lft, cfg.preferred_lft);

Once that has been computed, cfg.preferred_lft is already at its
maximum allowed value. There is no case where the RFC allows
increasing that value after doing that computation.

I think the safest thing to do is revert this change, and try to find
some other way to achieve the goal of preventing the user from
administratively setting a preferred lifetime that prevents temporary
addresses from being generated, when the user wants to use the privacy
extensions. For example, this could be done where administratively
configured values are accepted (wherever that is), and either generate
a warning or reject the change, if the value provided by the user is
lower than REGEN_ADVANCE.

-- Dan