Message-ID: <a25e2b7e899b9af7d25ea82f3a553fcc32c12052.camel@gmail.com>
Date: Sat, 25 Oct 2025 23:21:28 +0200
From: Garri Djavadyan <g.djavadyan@...il.com>
To: netdev@...r.kernel.org
Cc: Stephen Hemminger <stephen@...workplumber.org>, 1117959@...s.debian.org,
 	carnil@...ian.org
Subject: Re: ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared
 when static on-link routes are added during IPv6 address configuration

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@...il.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

Powered by blists - more mailing lists