[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKD1Yr1RMjQ=VD=V4Vr4gdUDa6_ZT62SEdKBSUP3PogQMRYyUA@mail.gmail.com>
Date: Wed, 8 Jul 2015 17:19:49 +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:09 PM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
> I wonder a little bit, because addresses which match the outgoing
> interface should get a higher score in saddr_eval, thus be automatically
> preferred. Is this check not strong enough?
It isn't strong enough because the "prefer outgoing interface" rule is
lower priority than other rules such as "prefer deprecated addresses"
and "prefer matching scope".
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.
> I really wonder if we can improve source address selection and make this
> behavior a default without introducing a new sysctl.
Another option I see is to change the behaviour to follow the RFC
recommendation, and thus always use the matching interface. Is that a
better option?
At the moment, we're going against the explicit recommendation of the
RFC, and I don't see a good reason for that.
--
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