On Mon, Mar 05, 2018 at 01:34:03PM -0800, David Ahern wrote:
> ipv6_chk_addr_and_flags determines if an address is a local address. It
> is called by ip6_route_info_create to validate a gateway address is not a
> local address. It currently does not consider L3 domains and as a result
> does not allow a route to be added in one VRF if the nexthop points to
> an address in a second VRF. e.g.,
> $ ip route add 2001:db8:1::/64 vrf r2 via 2001:db8:102::23
> Error: Invalid gateway address.
> where 2001:db8:102::23 is an address on an interface in vrf r1.
> Resolve by comparing the l3mdev for the passed in device and requiring an
> l3mdev match with the device containing an address. The intent of checking
> for an address on the specified device versus any device in the domain is
> mantained by a new argument to skip the check between the passed in device
> and the device with the address.
> Update the handful of users of ipv6_chk_addr with a NULL dev argument:
I see at least two callers from net/sctp/ipv6.c that pass a NULL
argument, which means they only want an address check, but you pass
'false' to 'skip_dev_check'.
> - anycast to call ipv6_chk_addr_and_flags. If the device is given by the
> user, look for the given address across the L3 domain. If the index is
> not given, the default table is presumed so only addresses on devices
> not enslaved are considered.
> - ip6_tnl_rcv_ctl - local address must exist on device, remote address
> can not exist in L3 domain; only remote check needs to be updated but
> do both for consistency.
> ip6_validate_gw needs to handle 2 cases - one where the device is given
> as part of the nexthop spec and the other where the device is resolved.
> There is at least 1 VRF case where deferring the check to only after
> the route lookup has resolved the device fails with an unintuitive error
> "RTNETLINK answers: No route to host" as opposed to the preferred
> "Error: Gateway can not be a local address." The 'no route to host'
> error is because of the fallback to a full lookup.
> Signed-off-by: David Ahern <dsah...@gmail.com>