Control: tags -1 + moreinfo On Sat, May 16, 2026 at 03:37:56AM +0200, Andreas Ferber wrote: > Package: src:linux > Version: 7.0.4-1~bpo13+1 > Severity: normal > Tags: ipv6 > X-Debbugs-Cc: [email protected] > User: [email protected] > Usertags: amd64 > > Hi, > > this may be related to my other bug report about premature renewal of > IPv6 temporary addresses (#1136792). > > On my main LAN interface (br0) I have IPv6 privacy extensions enabled > (sysctl net.ipv6.conf.br0.use_tempaddr=2). Since upgrading to this > kernel (7.0.4; previous version was linux-image-6.19.14+deb13-amd64) > when renewing temporary addresses the old addresses are dropped > immediately. This kills any existing TCP connections that are still > using the old address. > > Expected behavior would be that upon tempaddr renewal the old addresses > remain as deprecated addresses until their valid_lft runs out, thus > keeping TCP connections alive that are still using an old address. An > example from a different machine with an older Kernel: > > 7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP > group default qlen 1000 > link/ether <redacted> brd ff:ff:ff:ff:ff:ff > inet6 2a00:ffff:ffff:ffff:7608:e249:1da7:2ba4/64 scope global temporary > dynamic > valid_lft 86392sec preferred_lft 14392sec > inet6 2a00:ffff:ffff:ffff:9701:191c:1d06:e160/64 scope global temporary > deprecated dynamic > valid_lft 86392sec preferred_lft 0sec > inet6 2a00:ffff:ffff:ffff:d465:a610:62c7:85a5/64 scope global temporary > deprecated dynamic > valid_lft 86392sec preferred_lft 0sec > inet6 2a00:ffff:ffff:ffff::42/64 scope global noprefixroute > valid_lft forever preferred_lft forever > inet6 2a00:ffff:ffff:ffff:bca8:fe25:a3dd:d224/64 scope global temporary > deprecated dynamic > valid_lft 86392sec preferred_lft 0sec > > Note that this issue has nothing to do with the short valid_lft for the > public addresses (2a02:908:...) you can see in the network info below. > The issue also affects the ULA addresses (fd40:..) which have a much > longer lifetime, and I'm also seeing it on another machine in a > different network where the public prefix has a longer lifetime as well.
Same questions here as in #1136792, specifically https://bugs.debian.org/1136792#10 Regards, Salvatore
