From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>,
David Miller <davem@davemloft.net>
Cc: netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH] ipv6: update Destination Cache entries when gateway turn into host
Date: Mon, 12 May 2014 11:07:43 +0800 [thread overview]
Message-ID: <53703AFF.2040208@cn.fujitsu.com> (raw)
In-Reply-To: <1399856097.16759.116198185.2A93B8D8@webmail.messagingengine.com>
于 2014年05月12日 08:54, Hannes Frederic Sowa 写道:
> On Thu, May 8, 2014, at 20:24, Duan Jiong wrote:
>>
>> RFC 4861 states in 7.2.5:
>>
>> The IsRouter flag in the cache entry MUST be set based on the
>> Router flag in the received advertisement. In those cases
>> where the IsRouter flag changes from TRUE to FALSE as a result
>> of this update, the node MUST remove that router from the
>> Default Router List and update the Destination Cache entries
>> for all destinations using that neighbor as a router as
>> specified in Section 7.3.3. This is needed to detect when a
>> node that is used as a router stops forwarding packets due to
>> being configured as a host.
>>
>> Currently, when dealing with NA Message which IsRouter flag changes from
>> TRUE to FALSE, the kernel only removes router from the Default Router List,
>> and don't update the Destination Cache entries.
>>
>> Now in order to update those Destination Cache entries, i introduce
>> function rt6_clean_tohost().
>>
>> [...]
>>
>> +/*remove routers and update dst entries when gateway turn into host.*/
>> +static int fib6_clean_tohost(struct rt6_info *rt, void *arg)
>> +{
>> + struct in6_addr *gateway = (struct in6_addr *)arg;
>> +
>> + if (((rt->rt6i_flags & (RTF_ADDRCONF | RTF_DEFAULT | RTF_GATEWAY))
>> + == (RTF_ADDRCONF | RTF_DEFAULT | RTF_GATEWAY))
>> + && ipv6_addr_equal(gateway, &rt->rt6i_gateway)) {
>> + return -1;
>> + } else if (((rt->rt6i_flags & (RTF_GATEWAY | RTF_CACHE))
>> + == (RTF_GATEWAY | RTF_CACHE))
>> + && ipv6_addr_equal(gateway, &rt->rt6i_gateway)) {
>> + rt->rt6i_flags |= RTF_REJECT;
>> + rt->dst.error = -ENETUNREACH;
>> + }
>> + return 0;
>> +}
>
> I am not so happy with that but have not tried that.
>
> The Destination Cache you quote from the RFC (if you follow 7.3.3.) actually refers to the neighbouring
> subsystem, where we would need to generate subsequent errors in case we try to forward a packet
> through a this particular router.
>
> The reason why I am not that happy is, that the semantics when neighbour nodes are cleared is well
> defined but we don't have that semantics when those rt6_nodes get cleared up. E.g. consider a router which just temporarily switches forwarding off and on.
>
> I guess we need to inspect NTF_ROUTER flag in the output path somehow. :/
Why we need to inspect NTF_ROUTER flag?
In my opinion, the problem is that we can't use the neighbour node as next hop.
Actually, after a node switches from being a router to being a host, we should
perform next-hop determination rather than continue sending traffic to the former
router, so we could just delete those Destination Cache entries.
You can refer to the below:
RFC 4861 states in 6.3.5:
Whenever the Lifetime of an entry in the Default Router List expires,
that entry is discarded. When removing a router from the Default
Router list, the node MUST update the Destination Cache in such a way
that all entries using the router perform next-hop determination
again rather than continue sending traffic to the (deleted) router.
Thanks,
Duan
>
> Greetings,
>
> Hannes
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> .
>
next prev parent reply other threads:[~2014-05-12 3:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-09 3:24 [PATCH] ipv6: update Destination Cache entries when gateway turn into host Duan Jiong
2014-05-12 0:54 ` Hannes Frederic Sowa
2014-05-12 3:07 ` Duan Jiong [this message]
2014-05-12 10:13 ` Hannes Frederic Sowa
2014-05-12 5:01 ` David Miller
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=53703AFF.2040208@cn.fujitsu.com \
--to=duanj.fnst@cn.fujitsu.com \
--cc=davem@davemloft.net \
--cc=hannes@stressinduktion.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.