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

[David Ahern <dsahern@kernel.org>]

On 1/11/26 5:08 AM, Ido Schimmel wrote:
> 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(-)
> 

Reviewed-by: David Ahern <dsahern@kernel.org>