ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration

ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration

[Garri Djavadyan]

Hi Everyone,

A year ago I noticed a problem with handling ipv6_route flags that in
some scenarios can lead to reachability issues. It was reported here:

https://bugzilla.kernel.org/show_bug.cgi?id=219205


Also it was recently reported in the Debian tracker after checking if
the latest Debian stable is still affected:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1117959


Unfortunately, the Debian team cannot act on the report because no one
from the upstream kernel team has confirmed if the report in the
upstream tracker is valid or not. Therefore, I am checking if anyone
can help confirm if the observed behavior is indeed a bug.

Many thanks in advance!

Regards,
Garri

Re: ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration

[Stephen Hemminger]

On Thu, 16 Oct 2025 00:12:40 +0200
Garri Djavadyan <g.djavadyan@gmail.com> wrote:

> Hi Everyone,
> 
> A year ago I noticed a problem with handling ipv6_route flags that in
> some scenarios can lead to reachability issues. It was reported here:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=219205
> 
> 
> Also it was recently reported in the Debian tracker after checking if
> the latest Debian stable is still affected:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1117959
> 
> 
> Unfortunately, the Debian team cannot act on the report because no one
> from the upstream kernel team has confirmed if the report in the
> upstream tracker is valid or not. Therefore, I am checking if anyone
> can help confirm if the observed behavior is indeed a bug.
> 
> Many thanks in advance!
> 
> Regards,
> Garri
> 

Linux networking does not actively use kernel bugzilla.
I forward the reports to the mailing list, that is all.
After than sometimes developers go back and update bugzilla
but it is not required or expected.

Re: Bug#1117959: ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration

[Salvatore Bonaccorso]

Hi Garri,

On Sat, Oct 18, 2025 at 01:39:02AM -0700, Stephen Hemminger wrote:
> On Thu, 16 Oct 2025 00:12:40 +0200
> Garri Djavadyan <g.djavadyan@gmail.com> wrote:
> 
> > Hi Everyone,
> > 
> > A year ago I noticed a problem with handling ipv6_route flags that in
> > some scenarios can lead to reachability issues. It was reported here:
> > 
> > https://bugzilla.kernel.org/show_bug.cgi?id=219205
> > 
> > 
> > Also it was recently reported in the Debian tracker after checking if
> > the latest Debian stable is still affected:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1117959
> > 
> > 
> > Unfortunately, the Debian team cannot act on the report because no one
> > from the upstream kernel team has confirmed if the report in the
> > upstream tracker is valid or not. Therefore, I am checking if anyone
> > can help confirm if the observed behavior is indeed a bug.
> > 
> > Many thanks in advance!
> > 
> > Regards,
> > Garri
> > 
> 
> Linux networking does not actively use kernel bugzilla.
> I forward the reports to the mailing list, that is all.
> After than sometimes developers go back and update bugzilla
> but it is not required or expected.

Garri, best action would likely be to really post your full report on
netdev directly.

Regards,
Salvatore

Re: ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration

[Garri Djavadyan]

On Sat, 2025-10-25 at 16:53 +0200, Salvatore Bonaccorso wrote:
> Hi Garri,
> 
> On Sat, Oct 18, 2025 at 01:39:02AM -0700, Stephen Hemminger wrote:
> > On Thu, 16 Oct 2025 00:12:40 +0200
> > Garri Djavadyan <g.djavadyan@gmail.com> wrote:
> > 
> > > Hi Everyone,
> > > 
> > > A year ago I noticed a problem with handling ipv6_route flags
> > > that in
> > > some scenarios can lead to reachability issues. It was reported
> > > here:
> > > 
> > > https://bugzilla.kernel.org/show_bug.cgi?id=219205
> > > 
> > > 
> > > Also it was recently reported in the Debian tracker after
> > > checking if
> > > the latest Debian stable is still affected:
> > > 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1117959
> > > 
> > > 
> > > Unfortunately, the Debian team cannot act on the report because
> > > no one
> > > from the upstream kernel team has confirmed if the report in the
> > > upstream tracker is valid or not. Therefore, I am checking if
> > > anyone
> > > can help confirm if the observed behavior is indeed a bug.
> > > 
> > > Many thanks in advance!
> > > 
> > > Regards,
> > > Garri
> > > 
> > 
> > Linux networking does not actively use kernel bugzilla.
> > I forward the reports to the mailing list, that is all.
> > After than sometimes developers go back and update bugzilla
> > but it is not required or expected.
> 
> Garri, best action would likely be to really post your full report on
> netdev directly.
> 
> Regards,
> Salvatore


Thank you for your suggestions Stephen and Salvatore.

Below is the full report that was originally posted to the kernel
bugzilla a year ago. It is still reproducible with fresher kernels.

-----BEGIN REPORT-----
I noticed that the ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are
not cleared when static on-link routes are added during IPv6 address
configuration, and it leads to situations when the kernel updates the
static on-link routes with expiration time.

To replicate the problem I used the latest stable vanilla kernel
6.10.6, 2 network name spaces, and radvd with the following
configuration:


interface veth1
{
        AdvSendAdvert on;
        MinRtrAdvInterval 45;
        MaxRtrAdvInterval 60;
        AdvDefaultLifetime 0;
        AdvDefaultPreference low;
        AdvHomeAgentFlag off;
        prefix fd00::/64
        {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr off;
                AdvPreferredLifetime 60;
                AdvValidLifetime 120;
        };
};


When I first add a manual IPv6 address to the interface receiving
ICMPv6 RA packets and then receive an ICMPv6 RA with the same on-link
prefix, the packet is silently ignored and no ipv6_route flags,
including RTF_EXPIRES, get set on the static route. Everything works as
expected.

However, if an ICMPv6 RA is received before a static (manual) IPv6
address is set on the interface, and the RA route is installed in the
IPv6 route table, along with the ipv6_route flags RTF_ADDRCONF,
RTF_PREFIX_RT, and RTF_EXPIRES, only the flag RTF_EXPIRES gets cleared
when a manual IPv6 address is configured on the interface later. As a
result, after configuring the IPv6 address, it does not have any
associated expiration time, but the kernel still treats it as an RA-
learned route, so the next received RA packet sets the expiration time
again.

Below are the steps leading to the described issue:


# # Nothing is assigned to veth0 yet
#
# ip -6 addr show dev veth0
#


# # No fd00::/64 routes are present in the IPv6 route table
#
# grep ^fd /proc/net/ipv6_route 
# 


# # Received on-link prefix fd00::/64 from the router
#
# tcpdump -v -i veth0 'icmp6[0] == 134'
tcpdump: listening on veth0, link-type EN10MB (Ethernet), snapshot
length 262144 bytes

14:01:46.682452 IP6 (flowlabel 0x945ff, hlim 255, next-header ICMPv6
(58) payload length: 56) fe80::5c7f:f5ff:fe03:3b75 > ff02::1: [icmp6
sum ok] ICMP6, router advertisement, length 56
        hop limit 64, Flags [none], pref low, router lifetime 0s,
reachable time 0ms, retrans timer 0ms
          prefix info option (3), length 32 (4): fd00::/64, Flags
[onlink, auto], valid time 120s, pref. time 60s
          source link-address option (1), length 8 (1):
5e:7f:f5:03:3b:75
    
        
# # The RA route is installed in the ipv6_route structure with the
flags 0x004c0001
# # 0x4c: RTF_ADDRCONF, RTF_PREFIX_RT, and RTF_EXPIRES
#  
# grep ^fd /proc/net/ipv6_route 
fd000000000000000000000000000000 40 00000000000000000000000000000000 00
00000000000000000000000000000000 00000100 00000001 00000000 004c0001  
veth0


# # The route has a positive expiration time assigned as expected
#
# ip -6 ro
fd00::/64 dev veth0 proto kernel metric 256 expires 93sec pref medium


# # Now, the manual IPv6 address from the subnet fd00::/64 is
configured on the interface
#
# ip addr add fd00::2/64 dev veth0
# ip -6 addr show dev veth0
4: veth0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP group default qlen 1000 link-netns server
    inet6 fd00::2/64 scope global tentative 
       valid_lft forever preferred_lft forever


# # The ipv6_route entry for fd00::/64 gets updated: the flags are
changed to 0x000c0001.
# # 0x0c: RTF_ADDRCONF, RTF_PREFIX_RT
# # The flag RTF_EXPIRES is removed but the flags RTF_ADDRCONF,
RTF_PREFIX_RT are still set.
#
# grep ^fd /proc/net/ipv6_route 
fd000000000000000000000000000000 40 00000000000000000000000000000000 00
00000000000000000000000000000000 00000100 00000001 00000000 000c0001  
veth0
fd000000000000000000000000000002 80 00000000000000000000000000000000 00
00000000000000000000000000000000 00000000 00000002 00000000 80200001  
veth0


# # From user's perspective the on-link route looks permanent, no
expiration time is present
#
# ip -6 ro
fd00::/64 dev veth0 proto kernel metric 256 pref medium


# # Now, the RA packet is received again
#
14:18:13.920115 IP6 (flowlabel 0x945ff, hlim 255, next-header ICMPv6
(58) payload length: 56) fe80::5c7f:f5ff:fe03:3b75 > ff02::1: [icmp6
sum ok] ICMP6, router advertisement, length 56
        hop limit 64, Flags [none], pref low, router lifetime 0s,
reachable time 0ms, retrans timer 0ms
          prefix info option (3), length 32 (4): fd00::/64, Flags
[onlink, auto], valid time 120s, pref. time 60s
          source link-address option (1), length 8 (1):
5e:7f:f5:03:3b:75


# # And the permanent route turned into a temporary one again
(0x004c0001)
#
# grep ^fd /proc/net/ipv6_route 
fd000000000000000000000000000000 40 00000000000000000000000000000000 00
00000000000000000000000000000000 00000100 00000001 00000000 004c0001  
veth0
fd000000000000000000000000000002 80 00000000000000000000000000000000 00
00000000000000000000000000000000 00000000 00000002 00000000 80200001  
veth0
#
# ip -6 ro
fd00::/64 dev veth0 proto kernel metric 256 expires 113sec pref medium


# # At this poing, the routes is still reachable
#
# ping -c1 fd00::1
PING fd00::1 (fd00::1) 56 data bytes
64 bytes from fd00::1: icmp_seq=1 ttl=64 time=0.115 ms

--- fd00::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.115/0.115/0.115/0.000 ms


# # After stopping radvd and waiting for 2 minutes, the on-link route
gets unreachable
# # while the manual IPv6 address is still present on the interface
#
# ip -6 ro
fd00::/64 dev veth0 proto kernel metric 256 expires -969sec pref medium
#
# ping fd00::1
ping: connect: Network is unreachable


In some environements, in which RA-sending routers are present and the
RA processing is disabled by the interface init scripts a race
condition may lead to automatic removal of the permanent on-link
routes. For example:

1. The OS boots, RAs are accepted;
2. RA with Prefix Information option (PIO) is received from router #1;
3. the kernel installs a temporary on-link route;
4. the OS's init scripts configure a manual IPv6 address;
5. the kernel removes the expiration time from the on-link route;
6. RA with PIO is received from router #2;
7. the kernel sets the expiration time to the on-link route;
8. the OS's init scripts set 'net.ipv6.conf.xxx.accept_ra = 0' for the
interface;
9. the installed IPv6 route is no longer updated by the RAs;
10. the installed IPv6 route expires after N seconds


The problem was first noticed on a Debian system running kernel
5.10.197-1 but was replicated with a vanilla kernel 6.10.6.
-----END REPORT-----

Thank you.

Regards,
Garri

Re: ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration

[Fernando Fernandez Mancera]

On 10/25/25 11:21 PM, Garri Djavadyan wrote:
> On Sat, 2025-10-25 at 16:53 +0200, Salvatore Bonaccorso wrote:
>> Hi Garri,
>>
>> On Sat, Oct 18, 2025 at 01:39:02AM -0700, Stephen Hemminger wrote:
>>> On Thu, 16 Oct 2025 00:12:40 +0200
>>> Garri Djavadyan <g.djavadyan@gmail.com> wrote:
>>>
>>>> Hi Everyone,
>>>>
>>>> A year ago I noticed a problem with handling ipv6_route flags
>>>> that in
>>>> some scenarios can lead to reachability issues. It was reported
>>>> here:
>>>>
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=219205
>>>>
>>>>
>>>> Also it was recently reported in the Debian tracker after
>>>> checking if
>>>> the latest Debian stable is still affected:
>>>>
>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1117959
>>>>
>>>>
>>>> Unfortunately, the Debian team cannot act on the report because
>>>> no one
>>>> from the upstream kernel team has confirmed if the report in the
>>>> upstream tracker is valid or not. Therefore, I am checking if
>>>> anyone
>>>> can help confirm if the observed behavior is indeed a bug.
>>>>
>>>> Many thanks in advance!
>>>>
>>>> Regards,
>>>> Garri
>>>>
>>>
>>> Linux networking does not actively use kernel bugzilla.
>>> I forward the reports to the mailing list, that is all.
>>> After than sometimes developers go back and update bugzilla
>>> but it is not required or expected.
>>
>> Garri, best action would likely be to really post your full report on
>> netdev directly.
>>
>> Regards,
>> Salvatore
> 
> 
> Thank you for your suggestions Stephen and Salvatore.
> 
> Below is the full report that was originally posted to the kernel
> bugzilla a year ago. It is still reproducible with fresher kernels.
> 
> -----BEGIN REPORT-----
> I noticed that the ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are
> not cleared when static on-link routes are added during IPv6 address
> configuration, and it leads to situations when the kernel updates the
> static on-link routes with expiration time.
> 

This is indeed a bug, I have a patch already and I am doing some testing 
before sending it to net.git. I hope it can be sent tomorrow.

Thanks,
Fernando.