* Re: ipv6_route flags RTF_ADDRCONF and RTF_PREFIX_RT are not cleared when static on-link routes are added during IPv6 address configuration
2025-10-25 14:53 ` Bug#1117959: " Salvatore Bonaccorso
@ 2025-10-25 21:21 ` Garri Djavadyan
2025-11-10 16:54 ` Fernando Fernandez Mancera
0 siblings, 1 reply; 5+ messages in thread
From: Garri Djavadyan @ 2025-10-25 21:21 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, 1117959, carnil
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
^ permalink raw reply [flat|nested] 5+ messages in thread