| Message ID | 20250317224300.25985-1-kernel@sandropischinger.de (mailing list archive) |
|---|---|
| State | New |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [bug,report,net-next] lo.disable_ipv6=1 allows ::1 dst packet to take a default route | expand |
diff --git a/net/ipv6/route.c b/net/ipv6/route.c index fb2e99a56529..b27844de3baa 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -2193,6 +2193,12 @@ int fib6_table_lookup(struct net *net, struct fib6_table *table, int oif, redo_rt6_select: rt6_select(net, fn, oif, res, strict); + if (ipv6_addr_loopback(&fl6->daddr)) { + struct fib6_info *rt = res->f6i; + + if (!rt || !(rt->fib6_flags & RTF_LOCAL)) + res->f6i = net->ipv6.fib6_null_entry; + } if (res->f6i == net->ipv6.fib6_null_entry) { fn = fib6_backtrack(fn, &fl6->saddr); if (fn)
Hello all, I stumbled upon an issue when disabling ipv6 just for the loopback device. Afer doing so, sending a packet with destination ::1 will follow an available default route, if exists, e.g. "default via fe80::2 dev ens3". This seems to contradict RFC4291 2.5.3, which states that loopback packets must never leave the node. Using mainline kernel v6.14-rc7, configured with x86_64_defconfig and kvm_guest.config on archlinux (in qemu): $ ip -6 r fe80::/64 dev ens3 proto kernel metric 256 pref medium fec0::/64 dev ens3 proto ra metric 1002 pref medium multicast ff00::/8 dev ens3 proto kernel metric 256 pref medium default via fe80::2 dev ens3 proto ra metric 1002 pref medium $ ip -6 r get ::1 local ::1 dev lo proto kernel src ::1 metric 0 pref medium $ sysctl -w net.ipv6.conf.lo.disable_ipv6=1 net.ipv6.conf.lo.disable_ipv6 = 1 $ ip -6 r get ::1 ::1 via fe80::2 dev ens3 proto ra src fe80::c9cb:505e:82a2:8ca7 metric 1002 pref medium When observing trace events `fib6_table_lookup` for ping ::1, then we see that the ens3 device is selected for the case when ipv6 is disabled for lo: == lo.disable_ipv6=0 ping-356 [000] ..... 292.199930: fib6_table_lookup: (ffffffff84041fd4) ping-356 [000] ..... 292.199932: fib6_table_lookup: table 254 oif 0 iif 1 proto 17 ::/56460 -> ::1/1025 flowlabel 0 tos 0 scope 0 flags 0 ==> dev lo gw :: err 0 ping-356 [000] ..... 292.200176: fib6_table_lookup: (ffffffff84041fd4) ping-356 [000] ..... 292.200176: fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> ::1/0 flowlabel 0 tos 0 scope 0 flags 0 ==> dev lo gw :: err 0 ping-356 [000] ..s2. 292.200187: fib6_table_lookup: (ffffffff84041fd4) ping-356 [000] ..s2. 292.200187: fib6_table_lookup: table 254 oif 1 iif 1 proto 58 ::1/0 -> ::1/0 flowlabel 0 tos 0 scope 0 flags 0 ==> dev lo gw :: err 0 ping-356 [000] ..... 293.255592: fib6_table_lookup: (ffffffff84041fd4) ping-356 [000] ..... 293.255594: fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> ::1/0 flowlabel 0 tos 0 scope 0 flags 0 ==> dev lo gw :: err 0 ping-356 [000] ..s2. 293.255606: fib6_table_lookup: (ffffffff84041fd4) ping-356 [000] ..s2. 293.255606: fib6_table_lookup: table 254 oif 1 iif 1 proto 58 ::1/0 -> ::1/0 flowlabel 0 tos 0 scope 0 flags 0 ==> dev lo gw :: err 0 ping-356 [000] ..... 294.279429: fib6_table_lookup: (ffffffff84041fd4) ping-356 [000] ..... 294.279430: fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> ::1/0 flowlabel 0 tos 0 scope 0 flags 0 ==> dev lo gw :: err 0 ping-356 [000] ..s2. 294.279441: fib6_table_lookup: (ffffffff84041fd4) ping-356 [000] ..s2. 294.279441: fib6_table_lookup: table 254 oif 1 iif 1 proto 58 ::1/0 -> ::1/0 flowlabel 0 tos 0 scope 0 flags 0 ==> dev lo gw :: err 0 ping-356 [000] ..... 295.303440: fib6_table_lookup: (ffffffff84041fd4) ping-356 [000] ..... 295.303442: fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> ::1/0 flowlabel 0 tos 0 scope 0 flags 0 ==> dev lo gw :: err 0 ping-356 [000] ..s2. 295.303451: fib6_table_lookup: (ffffffff84041fd4) ping-356 [000] ..s2. 295.303452: fib6_table_lookup: table 254 oif 1 iif 1 proto 58 ::1/0 -> ::1/0 flowlabel 0 tos 0 scope 0 flags 0 ==> dev lo gw :: err 0 == lo.disable_ipv6=1 ping-363 [000] ..... 358.104211: fib6_table_lookup: (ffffffff84041fd4) ping-363 [000] ..... 358.104213: fib6_table_lookup: table 254 oif 0 iif 1 proto 17 ::/37566 -> ::1/1025 flowlabel 0 tos 0 scope 0 flags 0 ==> dev ens3 gw fe80::2 err 0 ping-363 [000] ..... 358.104453: fib6_table_lookup: (ffffffff84041fd4) ping-363 [000] ..... 358.104453: fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> ::1/0 flowlabel 0 tos 0 scope 0 flags 0 ==> dev ens3 gw fe80::2 err 0 ping-363 [000] ..... 359.111414: fib6_table_lookup: (ffffffff84041fd4) ping-363 [000] ..... 359.111415: fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> ::1/0 flowlabel 0 tos 0 scope 0 flags 0 ==> dev ens3 gw fe80::2 err 0 ping-363 [000] ..... 360.135436: fib6_table_lookup: (ffffffff84041fd4) ping-363 [000] ..... 360.135437: fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> ::1/0 flowlabel 0 tos 0 scope 0 flags 0 ==> dev ens3 gw fe80::2 err 0 ping-363 [000] ..... 361.159595: fib6_table_lookup: (ffffffff84041fd4) ping-363 [000] ..... 361.159597: fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> ::1/0 flowlabel 0 tos 0 scope 0 flags 0 ==> dev ens3 gw fe80::2 err 0 ping-363 [000] ..... 362.183614: fib6_table_lookup: (ffffffff84041fd4) ping-363 [000] ..... 362.183616: fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> ::1/0 flowlabel 0 tos 0 scope 0 flags 0 ==> dev ens3 gw fe80::2 err 0 ping-363 [000] ..... 363.207450: fib6_table_lookup: (ffffffff84041fd4) ping-363 [000] ..... 363.207452: fib6_table_lookup: table 254 oif 0 iif 1 proto 58 ::/0 -> ::1/0 flowlabel 0 tos 0 scope 0 flags 0 ==> dev ens3 gw fe80::2 err 0 ksoftirqd/0-16 [000] ..s.. 363.527470: fib6_table_lookup: (ffffffff84041fd4) ksoftirqd/0-16 [000] ..s.. 363.527471: fib6_table_lookup: table 254 oif 0 iif 2 proto 58 fe80::2/0 -> fe80::c9cb:505e:82a2:8ca7/0 flowlabel 0 tos 0 scope 0 flags 0 ==> dev ens3 gw :: err 0 Intuitively I would expect `ping ::1` to fail with `ping: connect: Network is unreachable`, as it does if there's no default route configured. However if there is one, then ping just continues trying to send packets via the matching default route. $ ping ::1 PING ::1 (::1) 56 data bytes ^C ::1 ping statistics --- 11 packets transmitted, 0 received, 100% packet loss, time 10230ms Searching through the netdev mailing list archive, I found a somewaht related discussion, where special handling for ::1 was mentioned. In particular one comment by Stephen Hemminger was: as found in https://lore.kernel.org/netdev/20101216132812.2d7fd885@nehalam/ Message-ID: <20101216132812.2d7fd885@nehalam> : > When loopback device is being brought down, then keep the route table > entries because they are special. The entries in the local table for > linklocal routes and ::1 address should not be purged. I don't understand enough of kernel IPv6 networking in order to known if this is (still) the case today. Is this behavior intended? If not, here's my draft patch for this, though I'm not familiar with the codebase and cannot foresee any side-effects. Best regards, Sandro Pischinger Signed-off-by: Sandro Pischinger <kernel@sandropischinger.de> --- net/ipv6/route.c | 6 ++++++ 1 file changed, 6 insertions(+)