All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@idosch.org>
To: David Ahern <dsahern@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH v2 net-next 2/5] net/ipv6: Address checks need to consider the L3 domain
Date: Tue, 6 Mar 2018 17:01:48 +0200	[thread overview]
Message-ID: <20180306150148.GA6675@splinter> (raw)
In-Reply-To: <20180305213406.13628-3-dsahern@gmail.com>

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 <dsahern@gmail.com>

  reply	other threads:[~2018-03-06 15:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-05 21:34 [PATCH v2 net-next 0/5] net/ipv6: Address checks need to consider the L3 domain David Ahern
2018-03-05 21:34 ` [PATCH v2 net-next 1/5] net/ipv6: Refactor gateway validation on route add David Ahern
2018-03-05 21:34 ` [PATCH v2 net-next 2/5] net/ipv6: Address checks need to consider the L3 domain David Ahern
2018-03-06 15:01   ` Ido Schimmel [this message]
2018-03-06 18:32     ` David Ahern
2018-03-05 21:34 ` [PATCH v2 net-next 3/5] selftests: fib_tests: Use an alias for ip command David Ahern
2018-03-05 21:34 ` [PATCH v2 net-next 4/5] selftests: fib_tests: Allow user to run a specific test David Ahern
2018-03-05 21:34 ` [PATCH v2 net-next 5/5] selftests: fib_tests: Add IPv6 nexthop spec tests David Ahern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180306150148.GA6675@splinter \
    --to=idosch@idosch.org \
    --cc=dsahern@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.