From: David Miller <davem@davemloft.net>
To: ek@google.com
Cc: hannes@stressinduktion.org, lorenzo@google.com,
hideaki.yoshifuji@miraclelinux.com, netdev@vger.kernel.org
Subject: Re: [PATCH net-next v2] ipv6: sysctl to restrict candidate source addresses
Date: Wed, 08 Jul 2015 14:41:08 -0700 (PDT) [thread overview]
Message-ID: <20150708.144108.1074660115445698837.davem@davemloft.net> (raw)
In-Reply-To: <CAAedzxqvEx+dMCmM5YLbnmd9REpcWFi=+nZ4s0EaBe8mxSKKgQ@mail.gmail.com>
From: Erik Kline <ek@google.com>
Date: Wed, 8 Jul 2015 21:41:58 +0900
>> 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.
>>
>> Maybe we can tweak saddr_eval a bit.
>
> I think it all comes down to this: source address selection really
> doesn't know anything about routing that could help it make a better
> evaluation.
>
> Reading the RFCs that seems to be by design, or at the very least
> there is a kind of "implied flat-ish routing table" at work, which the
> algorithm works around by having various "prefer same interface" type
> of rules. So, after the routing lookup to determine outgoing interface
> it's just looking at all the addresses on all the interfaces. There
> is no checking of any of the multiple possible routing tables, in part
> because there just isn't all the right information available.
>
> So, I figured the safe thing to do would be to not change existing
> default behaviour but just introduce a knob to at least make it
> possible to get the RFC recommended behaviour.
>
> ---
>
> Re: not having a source address or returning a link-local source for a
> global destination: I think that's perfectly ok, if the knob is set.
> Frequently the source address will just be tossed into a salad bowl of
> (src, dst) pairs returned from DNS and 3484/6724 sorting will then
> help pick a more globally optimum (src, dst) to work with.
The fact is, if wireless APs are going to reject packets sent out in
the very circumstances this is claiming to help, our default behavior
is broken because communication is not possible.
So we should look at a way at making the new behavior the default, and
in fact that makes sense and we can even optimize this piece of saddr
selection code to not do an iteration over all devices in the system
for no reason at all. It can just do a quick dev_get_by_index() and
work with that.
next prev parent reply other threads:[~2015-07-08 21:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-06 3:05 [PATCH net-next v2] ipv6: sysctl to restrict candidate source addresses Erik Kline
2015-07-08 1:29 ` Lorenzo Colitti
2015-07-08 8:09 ` Hannes Frederic Sowa
2015-07-08 8:19 ` Lorenzo Colitti
2015-07-08 8:43 ` Hannes Frederic Sowa
2015-07-08 11:17 ` Lorenzo Colitti
2015-07-08 12:41 ` Erik Kline
2015-07-08 21:41 ` David Miller [this message]
2015-07-10 6:47 ` YOSHIFUJI Hideaki
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=20150708.144108.1074660115445698837.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=ek@google.com \
--cc=hannes@stressinduktion.org \
--cc=hideaki.yoshifuji@miraclelinux.com \
--cc=lorenzo@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).