[BUG] some temporary IPv6 address don't get regenerated

[BUG] some temporary IPv6 address don't get regenerated

[Łukasz Stelmach]

Hi,

Apparently, something in addrconf.c can go wrong and a temporary
addresses may not get regenerated leaving users who wish to use them
with only the stable ones. Below, 2a01:110f:4321:1002:abcc:78d7:2055:94ec
while still valid is not preferred anymore. Even if it's not the only
global temporary address it is the only usable to contact hosts on the
Internet because the other temporary addresses are ULA.

Neither received RAs nor adding and removing an address manually (one
with a different prefix unrelated to these below) which as far as I
understand, should trigger address maintenance code.

I noticed this phenomenon once or twice before. It seems to be very
rare, yet quite undesirable I'd say. What might have triggered it today
is a reboot of my router and (possible?) change in lifetime values it
announced.

Even stranger is that there is a preferred fd89:: (ULA), but not 2a01::.

accept_ra as well as use_tempaddr are set to 2.

Of course, this ma be get fixed by a suspend/resume (no, it may not) or
manual ifdown/ifup (of course it helped), but nevertheless I thought it
was worth reporting.

--8<---------------cut here---------------start------------->8---
107: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether b8:ca:3a:d4:1e:97 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.122/24 brd 192.168.2.255 scope global dynamic bond0
       valid_lft 165585sec preferred_lft 165585sec

    inet6 fd89:82bb:420:2:cab3:d2d6:aeeb:e250/64 scope global temporary dynamic 
       valid_lft 597079sec preferred_lft 78177sec

    inet6 2a01:110f:4321:1002:abcc:78d7:2055:94ec/64 scope global temporary deprecated dynamic 
       valid_lft 60815sec preferred_lft 0sec

    inet6 2a01:110f:4321:1002:abac:3aff:fed4:beef/64 scope global dynamic mngtmpaddr proto kernel_ra 
       valid_lft 60815sec preferred_lft 60815sec

    inet6 fd89:82bb:420:2:24bf:fe8f:5c9c:c753/64 scope global temporary deprecated dynamic 
       valid_lft 511186sec preferred_lft 0sec

    inet6 fd89:82bb:420:2:abac:3aff:fed4:beef/64 scope global dynamic mngtmpaddr proto kernel_ra 
       valid_lft 2591805sec preferred_lft 604605sec

    inet6 fe80::abac:3aff:fed4:beef/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
--8<---------------cut here---------------end--------------->8---

-- 
Kind regards,
Łukasz Stelmach

Re: [BUG] some temporary IPv6 address don't get regenerated

[Fernando Fernandez Mancera]

On 4/17/26 5:23 PM, Łukasz Stelmach wrote:
> Hi,
> 
> Apparently, something in addrconf.c can go wrong and a temporary
> addresses may not get regenerated leaving users who wish to use them
> with only the stable ones. Below, 2a01:110f:4321:1002:abcc:78d7:2055:94ec
> while still valid is not preferred anymore. Even if it's not the only
> global temporary address it is the only usable to contact hosts on the
> Internet because the other temporary addresses are ULA.
> 

Hi,

I managed to reproduce this, it took me quite some time. It looks like a 
race condition somewhere. I am working on a fix and I will add a 
selftest covering this too.

Ideally, I will send a fix this week. I am now checking if this was 
introduced recently or was always broken.

> Neither received RAs nor adding and removing an address manually (one
> with a different prefix unrelated to these below) which as far as I
> understand, should trigger address maintenance code.
> 

Yup, same situation here.

Thanks,
Fernando.

> I noticed this phenomenon once or twice before. It seems to be very
> rare, yet quite undesirable I'd say. What might have triggered it today
> is a reboot of my router and (possible?) change in lifetime values it
> announced.
> 
> Even stranger is that there is a preferred fd89:: (ULA), but not 2a01::.
> 
> accept_ra as well as use_tempaddr are set to 2.
> 
> Of course, this ma be get fixed by a suspend/resume (no, it may not) or
> manual ifdown/ifup (of course it helped), but nevertheless I thought it
> was worth reporting.
> 
> --8<---------------cut here---------------start------------->8---
> 107: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
>      link/ether b8:ca:3a:d4:1e:97 brd ff:ff:ff:ff:ff:ff
>      inet 192.168.2.122/24 brd 192.168.2.255 scope global dynamic bond0
>         valid_lft 165585sec preferred_lft 165585sec
> 
>      inet6 fd89:82bb:420:2:cab3:d2d6:aeeb:e250/64 scope global temporary dynamic
>         valid_lft 597079sec preferred_lft 78177sec
> 
>      inet6 2a01:110f:4321:1002:abcc:78d7:2055:94ec/64 scope global temporary deprecated dynamic
>         valid_lft 60815sec preferred_lft 0sec
> 
>      inet6 2a01:110f:4321:1002:abac:3aff:fed4:beef/64 scope global dynamic mngtmpaddr proto kernel_ra
>         valid_lft 60815sec preferred_lft 60815sec
> 
>      inet6 fd89:82bb:420:2:24bf:fe8f:5c9c:c753/64 scope global temporary deprecated dynamic
>         valid_lft 511186sec preferred_lft 0sec
> 
>      inet6 fd89:82bb:420:2:abac:3aff:fed4:beef/64 scope global dynamic mngtmpaddr proto kernel_ra
>         valid_lft 2591805sec preferred_lft 604605sec
> 
>      inet6 fe80::abac:3aff:fed4:beef/64 scope link proto kernel_ll
>         valid_lft forever preferred_lft forever
> --8<---------------cut here---------------end--------------->8---
>