Date:	Wed, 8 Jul 2015 20:17:40 +0900
From:	Lorenzo Colitti <lorenzo@...gle.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	Erik Kline <ek@...gle.com>,
	吉藤英明 <hideaki.yoshifuji@...aclelinux.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH net-next v2] ipv6: sysctl to restrict candidate source addresses

On Wed, Jul 8, 2015 at 5:43 PM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
>> For example, consider the case where you have an IPv6 default route
>> but not an IPv6 address on one interface (e.g., wifi), and a working
>> configuration (IPv6 default route and IPv6 address) on another
>> interface (e.g., cellular data). In this situation, the host will send
>> the packet out on the wifi interface using the source address from the
>> the cellular interface to try to talk to wifi. This will not work
>> because the wifi network will almost certainly drop the packet due to
>> BCP-38 ingress filtering.
>
> So in this case we report errors to user space instead of picking an
> address from another interface.

So you're proposing that when the sysctl is turned on, if we've picked
an outgoing interface, but that interface only has a link-local
address, then we return EADDRNOTAVAIL instead of picking the
link-local address?

That would preclude the ability to use a link-local address to talk to
an on-link (directly-connected) global address, which is possible
today. But it's at least better than the current behaviour. I'm not
sure how to implement this though - I think it's equivalent to
ordering rule 5 above rule 2, but that's a pretty big change and hard
to make in the current code because the rules are an enum.

> If we turn on this knob unconditionally
> we cannot leave the set of possible source addresses empty, this will
> change application behavior and admin habits too much, I fear.

In general, even if the user turns on this setting, there will always
be at least one address - the link-local address on the interface.
That's what RFC 6724 says the host should use. In this case, what will
happen is that once the source address lookup is complete, when
getaddrinfo() chooses the destination address, it will sort this
combination last, because of rule 2 (prefer matching scope), which is
the highest priority rule apart from rule 1 (avoid unreachable). So
the application will try other combinations, which will include
falling back to IPv4 in the likely case that it is available.

What happens today is that getaddrinfo sorts the (global address, ipv6
address on wrong interface) combination first, and the app gets stuck.

>> At the moment, we're going against the explicit recommendation of the
>> RFC, and I don't see a good reason for that.
>
> I really would like to come up with a sane works-always behavior for
> this, but besides doing a retry on the complete source address selection
> algorithm I currently cannot come up with an idea.

Nothing is works-always in the presence of broken configurations. I
think we should have a mode where we follow the RFC, because in that
case when we get stuck we can convincingly argue that the network is
broken and not our implementation.

In IETF language, "RECOMMENDED" means that "there may exist valid
reasons in particular circumstances to ignore a particular item, but
the full implications must be understood and carefully weighed before
choosing a different course". What I don't understand is - what's the
harm here if we provide a mode that follows the RFC? What are do
gaining by not following it?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists