Received-SPF: pass (google.com: domain of linux-kernel+bounces-13160-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
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: Fri, 29 Dec 2023 09:33:39 -0700
Message-ID: <20231229163339.2716-1-dan@danm.net>
In-Reply-To: <CAMMLpeTCZDakqdkxm+jvQHxbRXhCYd4_PK+VVqMAmZHjSPuPRw@mail.gmail.com>
References: <CAMMLpeTCZDakqdkxm+jvQHxbRXhCYd4_PK+VVqMAmZHjSPuPRw@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

I think a maintainer will probably need to make a call here and decide
how to proceed.

> TEMP_PREFERRED_LIFETIME is an administratively set variable: The user
> can change it to whatever they want whenever they want, and the
> operating system can adjust it automatically too.

Agreed. And the behavior it seems you really want is to prevent the
user from administratively setting it to a value that is lower than
REGEN_ADVANCE, so that it won't stop generating new temporary
addresses altogether.

But preventing the user from configuring it to a value that is too low
is different from generating new temporary addresses with preferred
lifetimes that are greater than the currently configured value of
TEMP_PREFERRED_LIFETIME. I still believe it would be better, and would
be in conformance with the RFC, to simply not allow the user to
configure a too-short TEMP_PREFERRED_LIFETIME instead of tinkering
with the lifetimes of generated temporary addresses.

> It's fine to revert the commit for version 6.7 (after all, I think
> everyone wants a break for the holidays). Hopefully by version 6.8 we
> can agree on a way to support users who want to randomize their IPv6
> address as frequently as the network allows.

FWIW, I think the desired effect you are seeking makes sense and is
the right thing to do. I'm just not convinced this is the correct way
to do it. But I'm not a maintainer and also not an expert in IPv6, so
I'm definitely not the right person to make that call.

-- Dan