From: arno@natisbad•org (Arnaud Ebalard)
To: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6•org>
Cc: Brian Haley <brian.haley@hp•com>,
David Miller <davem@davemloft•net>, Jiri Olsa <jolsa@redhat•com>,
Scott Otto <scott.otto@alcatel-lucent•com>,
netdev@vger•kernel.org
Subject: Re: [REGRESSION,BISECTED] MIPv6 support broken by f4f914b58019f0
Date: Fri, 28 May 2010 23:15:55 +0200 [thread overview]
Message-ID: <87ljb3ohh0.fsf@small.ssi.corp> (raw)
In-Reply-To: <4C000E37.7080306@linux-ipv6.org> (YOSHIFUJI Hideaki's message of "Sat, 29 May 2010 03:40:55 +0900")
Hi,
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6•org> writes:
>>> I guess I always believed setting SO_BINDTODEVICE should always force
>>> traffic out that interface, but from Yoshifuji's email it seems that
>>> maybe wasn't the intention, at least for things that don't meet
>>> the rt_need_strict() criteria like globals. I don't know the history
>>> behind the setsockopt.
>>
>> The behavior I would expect from a combination of RFC 4191 and
>> SO_BINDTODEVICE sockopt would be the use of the interface as outgoing
>> interface and then the use of the best router (using router preference
>> info, reachability, ...) available on the subnet. IIRC, the router
>> preference info is per default router list in the RFC, i.e. per
>> interface.
>
> Good point.
>
> Whatever our original intention/thought was,
> current RFC says that we should honor outgoing interface
> specified by user (by IPV6_PKTINFO etc.), as we do for
> SO_BINDTODEVICE in IPv4 as well.
>
> In this sense, checking sk->sk_bound_dev_if in
> ip6_route_output() is not enough because we need to
> take outgoing interface specified in ancillary data
> into account, which is set to fl->oif.
>
> How about adding additional "flags" parameter
> for ip6_route_output()?
I think this may provide a better long term solution but getting all
combinations of cases (SO_BINDTODEVICE and other IPv6 sockopts) work
together (possibly with external info like RFC 4191 ones gathered from
RA or specific local routing config) will be a bit tricky.
Meanwhile, regarding the regression, as Brian's fix handles most
cases, I think it would be useful to apply it and push it to the
stable team.
Cheers,
a+
next prev parent reply other threads:[~2010-05-28 21:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-26 17:01 [REGRESSION,BISECTED] MIPv6 support broken by f4f914b58019f0 Arnaud Ebalard
2010-05-27 0:48 ` Brian Haley
2010-05-27 15:14 ` Arnaud Ebalard
2010-05-27 19:39 ` Brian Haley
2010-05-27 21:01 ` Arnaud Ebalard
2010-05-28 18:40 ` YOSHIFUJI Hideaki
2010-05-28 21:15 ` Arnaud Ebalard [this message]
2010-05-27 21:31 ` Scott C Otto
2010-05-28 8:51 ` Arnaud Ebalard
2010-05-28 17:59 ` Brian Haley
2010-05-28 18:17 ` [PATCH] IPv6: fix Mobile IPv6 regression Brian Haley
2010-05-29 6:03 ` David Miller
2010-05-31 8:46 ` Jiri Olsa
2010-05-31 12:49 ` Jiri Olsa
2010-05-27 17:39 ` [REGRESSION,BISECTED] MIPv6 support broken by f4f914b58019f0 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=87ljb3ohh0.fsf@small.ssi.corp \
--to=arno@natisbad$(echo .)org \
--cc=brian.haley@hp$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=jolsa@redhat$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=scott.otto@alcatel-lucent$(echo .)com \
--cc=yoshfuji@linux-ipv6$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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