[PATCH net-next 4/5] ipv6: Allow for nexthop device mismatch with "onlink"

[Ido Schimmel <idosch@nvidia.com>]

IPv4 allows for a nexthop device mismatch when the "onlink" keyword is
specified:

 # ip link add name dummy1 up type dummy
 # ip address add 192.0.2.1/24 dev dummy1
 # ip link add name dummy2 up type dummy
 # ip route add 198.51.100.0/24 nexthop via 192.0.2.2 dev dummy2
 Error: Nexthop has invalid gateway.
 # ip route add 198.51.100.0/24 nexthop via 192.0.2.2 dev dummy2 onlink
 # echo $?
 0

This seems to be consistent with the description of "onlink" in the
ip-route man page: "Pretend that the nexthop is directly attached to
this link, even if it does not match any interface prefix".

On the other hand, IPv6 rejects a nexthop device mismatch, even when
"onlink" is specified:

 # ip link add name dummy1 up type dummy
 # ip address add 2001:db8:1::1/64 dev dummy1
 # ip link add name dummy2 up type dummy
 # ip route add 2001:db8:10::/64 nexthop via 2001:db8:1::2 dev dummy2
 RTNETLINK answers: No route to host
 # ip route add 2001:db8:10::/64 nexthop via 2001:db8:1::2 dev dummy2 onlink
 Error: Nexthop has invalid gateway or device mismatch.

This is intentional according to commit fc1e64e1092f ("net/ipv6: Add
support for onlink flag") which added IPv6 "onlink" support and states
that "any unicast gateway is allowed as long as the gateway is not a
local address and if it resolves it must match the given device".

The condition was later relaxed in commit 4ed591c8ab44 ("net/ipv6: Allow
onlink routes to have a device mismatch if it is the default route") to
allow for a nexthop device mismatch if the gateway address is resolved
via the default route:

 # ip link add name dummy1 up type dummy
 # ip route add ::/0 dev dummy1
 # ip link add name dummy2 up type dummy
 # ip route add 2001:db8:10::/64 nexthop via 2001:db8:1::2 dev dummy2
 RTNETLINK answers: No route to host
 # ip route add 2001:db8:10::/64 nexthop via 2001:db8:1::2 dev dummy2 onlink
 # echo $?
 0

While the decision to forbid a nexthop device mismatch in IPv6 seems to
be intentional, it is unclear why it was made. Especially when it
differs from IPv4 and seems to go against the intended behavior of
"onlink".

Therefore, relax the condition further and allow for a nexthop device
mismatch when "onlink" is specified:

 # ip link add name dummy1 up type dummy
 # ip address add 2001:db8:1::1/64 dev dummy1
 # ip link add name dummy2 up type dummy
 # ip route add 2001:db8:10::/64 nexthop via 2001:db8:1::2 dev dummy2 onlink
 # echo $?
 0

The motivating use case is the fact that FRR would like to be able to
configure overlay routes of the following form:

 # ip route add <host-Z> vrf <VRF> encap ip id <ID> src <VTEP-A> dst <VTEP-Z> via <VTEP-Z> dev vxlan0 onlink

Where vxlan0 is in the default VRF in which "VTEP-Z" is reachable via
one of the underlay routes (e.g., via swpX). Without this patch, the
above only works with IPv4, but not with IPv6.

Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
 net/ipv6/route.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index a3e051dc66ee..00a8318f33a7 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3419,11 +3419,8 @@ static int ip6_route_check_nh_onlink(struct net *net,
 
 	err = ip6_nh_lookup_table(net, cfg, gw_addr, tbid, 0, &res);
 	if (!err && !(res.fib6_flags & RTF_REJECT) &&
-	    /* ignore match if it is the default route */
-	    !ipv6_addr_any(&res.f6i->fib6_dst.addr) &&
-	    (res.fib6_type != RTN_UNICAST || dev != res.nh->fib_nh_dev)) {
-		NL_SET_ERR_MSG(extack,
-			       "Nexthop has invalid gateway or device mismatch");
+	    res.fib6_type != RTN_UNICAST) {
+		NL_SET_ERR_MSG(extack, "Nexthop has invalid gateway");
 		err = -EINVAL;
 	}
 
-- 
2.52.0