From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCH v2 6/6] ipv6: Do route updating for redirect in ndisc layer
Date: Wed, 18 Sep 2013 06:13:37 +0200 [thread overview]
Message-ID: <20130918041337.GD8947@order.stressinduktion.org> (raw)
In-Reply-To: <5239076A.4080406@cn.fujitsu.com>
On Wed, Sep 18, 2013 at 09:52:42AM +0800, Duan Jiong wrote:
> 于 2013年09月18日 09:39, Hannes Frederic Sowa 写道:
> > On Tue, Sep 17, 2013 at 08:29:36PM -0400, David Miller wrote:
> >> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> >> Date: Fri, 13 Sep 2013 11:03:07 +0800
> >>
> >>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> >>>
> >>> Do the whole verification and route updating in ndisc
> >>> lay and then just call into icmpv6_notify() to notify
> >>> the upper protocols.
> >>>
> >>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> >>
> >> This is completely broken, and I believe your patch set fundamentally
> >> is too.
> >>
> >> We absolutely _must_ handle the redirect at the socket level when
> >> we are able to, otherwise we cannot specify the mark properly and
> >> the mark is an essential part of the key used to find the correct
> >> route to work with.
> >>
> >> I am not applying this patch series until you deal with this
> >> deficiency. I am not willing to consider changes which stop using the
> >> more precise keying information available from a socket.
> >
> > Oh, Duan, I am very sorry for not catching this earlier. We use the
> > sk->mark to select the proper routing table where we clone the rt6_info into.
> > And we only get that value out of the sockets. I missed that. We should leave
> > the redirect logic in the socket layer where it is possible.
> >
> > But parts of this series are still valid. We need to fix redirects for tunnels
> > and I do think we can still simplify some code in the error handlers.
> >
>
> I got it.
I gave it a bit more thought:
RFC 4861 8.3:
"
Redirect messages apply to all flows that are being sent to a given
destination. That is, upon receipt of a Redirect for a Destination
Address, all Destination Cache entries to that address should be
updated to use the specified next-hop, regardless of the contents of
the Flow Label field that appears in the Redirected Header option.
"
Especially because redirects also help in the on-link determination (same
RFC, section 8), I changed my mind and am still in favour of updating it
in the ndisc layer. In my opinion we just have to consider all routing
tables and apply the update to every one which carries a valid next hop
to the source of the redirect (under consideration of the destination).
This will be important if we actually try to get linux to correctly
implement the ipv6 subnet model (RFC 5942, Section 4 Rule 1). In that
case we are not allowed to assume nodes on-link even if they would match
the same prefix as a locally configured address.
Greetings,
Hannes
next prev parent reply other threads:[~2013-09-18 4:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-13 2:57 [PATCH v2 0/6] ipv6: Do route updating for redirect in ndisc layer Duan Jiong
2013-09-13 2:58 ` [PATCH v2 1/6] ipv6: del the statements for updating route in (dccp|tcp|sctp)_v6_err Duan Jiong
2013-09-13 20:37 ` Hannes Frederic Sowa
2013-09-14 8:20 ` Daniel Borkmann
2013-09-13 2:59 ` [PATCH v2 2/6] ipv6: just match on ICMPV6_PKT_TOOBIG in those err_handle Duan Jiong
2013-09-13 3:00 ` [PATCH v2 3/6] ipv6: del statements for dealing with NDISC_REDIRECT Duan Jiong
2013-09-13 3:01 ` [PATCH v2 4/6] ip6tnl: move route updating for redirect to ndisc layer Duan Jiong
2013-09-13 3:02 ` [PATCH v2 5/6] ipv6: modify the err to 0 when dealing with NDISC_REDIRECT Duan Jiong
2013-09-13 3:03 ` [PATCH v2 6/6] ipv6: Do route updating for redirect in ndisc layer Duan Jiong
2013-09-18 0:29 ` David Miller
2013-09-18 1:39 ` Hannes Frederic Sowa
2013-09-18 1:52 ` Duan Jiong
2013-09-18 4:13 ` Hannes Frederic Sowa [this message]
2013-09-18 11:57 ` Duan Jiong
2013-10-09 1:43 ` Hannes Frederic Sowa
2013-10-09 7:00 ` Duan Jiong
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=20130918041337.GD8947@order.stressinduktion.org \
--to=hannes@stressinduktion.org \
--cc=davem@davemloft.net \
--cc=duanj.fnst@cn.fujitsu.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).