From: David Ward <david.ward@ll.mit.edu>
To: Mark Smith <lk-netdev@lk-netdev.nosense.org>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH] Update Neighbor Cache when IPv6 RA is received on a router
Date: Sun, 16 Aug 2009 01:47:09 -0400 [thread overview]
Message-ID: <4A879D5D.1010202@ll.mit.edu> (raw)
In-Reply-To: <20090816120027.3d510139.lk-netdev@lk-netdev.nosense.org>
Mark, thank you very much for your response.
On 08/15/2009 10:30 PM, Mark Smith wrote:
> Hi David,
>
> On Sat, 15 Aug 2009 20:19:54 -0400
> David Ward <david.ward@ll.mit.edu> wrote:
>
>> When processing a received IPv6 Router Advertisement, the kernel
>> creates or updates an IPv6 Neighbor Cache entry for the sender --
>> but presently this does not occur if IPv6 forwarding is enabled
>> (net.ipv6.conf.*.forwarding = 1), or if IPv6 Router Advertisements
>> are not accepted (net.ipv6.conf.*.accept_ra = 0), because in these
>> cases processing of the Router Advertisement has already halted.
>>
>> This patch allows the Neighbor Cache to be updated in these cases,
>> while still avoiding any modification to routes or link parameters.
>>
>
> I'm a bit confused what benefit this has.
I apologize for not making that clear. It allows routers to utilize the
Neighbor Cache to keep track of neighboring routers, which are learned
about through the periodic Router Advertisements. By doing so,
applications communicating through upper layers can make use of the
Neighbor Cache, for example, as a basis for initiating dynamic peering
between neighboring routers. Non-routers are already able to keep track
of their neighboring routers in the Neighbor Cache; this simply allows
routers to do the same.
This cannot be achieved through Neighbor Advertisements, because they
are usually sent in response to a direct Neighbor Solicitation, while
Router Advertisements are periodically multicast to the all-nodes group.
> Is the intent to avoid a Neighbor Solicitation being triggered when a
> recent RA has already provided the router's link local address,
> therefore reducing by a small mount ND traffic?
No. This patch does not preclude the need to send a Neighbor
Solicitation to another router to determine reachability. That would
violate RFC 4861, which states that a Router Advertisement "MUST NOT be
treated as a reachability confirmation".
In the dynamic router peering scenario, the Neighbor Cache entry could
be used to learn that the neighboring router exists and is a potential
peer -- but reachability must still be determined before a peering
session could actually be attempted.
>> This continues to satisfy RFC 4861, since any entry created in the
>> Neighbor Cache as the result of a received Router Advertisement is
>> still placed in the STALE state.
>>
>> Signed-off-by: David Ward <david.ward@ll.mit.edu>
>> ---
>> net/ipv6/ndisc.c | 14 ++++++++------
>> 1 files changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
>> index 1ba42bd..44b4c87 100644
>> --- a/net/ipv6/ndisc.c
>> +++ b/net/ipv6/ndisc.c
>> @@ -1151,10 +1151,6 @@ static void ndisc_router_discovery(struct
>> sk_buff *skb)
>> skb->dev->name);
>> return;
>> }
>> - if (in6_dev->cnf.forwarding || !in6_dev->cnf.accept_ra) {
>> - in6_dev_put(in6_dev);
>> - return;
>> - }
>>
>> if (!ndisc_parse_options(opt, optlen, &ndopts)) {
>> in6_dev_put(in6_dev);
>> @@ -1163,6 +1159,10 @@ static void ndisc_router_discovery(struct
>> sk_buff *skb)
>> return;
>> }
>>
>> + /* skip route and link configuration on routers */
>> + if (in6_dev->cnf.forwarding || !in6_dev->cnf.accept_ra)
>> + goto skip_linkparms;
>> +
>> #ifdef CONFIG_IPV6_NDISC_NODETYPE
>> /* skip link-specific parameters from interior routers */
>> if (skb->ndisc_nodetype == NDISC_NODETYPE_NODEFAULT)
>> @@ -1283,9 +1283,7 @@ skip_defrtr:
>> }
>> }
>>
>> -#ifdef CONFIG_IPV6_NDISC_NODETYPE
>> skip_linkparms:
>> -#endif
>>
>> /*
>> * Process options.
>> @@ -1312,6 +1310,10 @@ skip_linkparms:
>> NEIGH_UPDATE_F_ISROUTER);
>> }
>>
>> + /* skip route and link configuration on routers */
>> + if (in6_dev->cnf.forwarding || !in6_dev->cnf.accept_ra)
>> + goto out;
>> +
>> #ifdef CONFIG_IPV6_ROUTE_INFO
>> if (in6_dev->cnf.accept_ra_rtr_pref && ndopts.nd_opts_ri) {
>> struct nd_opt_hdr *p;
>> --
>> 1.6.0.4
next prev parent reply other threads:[~2009-08-16 6:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-16 0:19 [PATCH] Update Neighbor Cache when IPv6 RA is received on a router David Ward
2009-08-16 2:30 ` Mark Smith
2009-08-16 5:47 ` David Ward [this message]
2009-08-29 7:04 ` 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=4A879D5D.1010202@ll.mit.edu \
--to=david.ward@ll.mit.edu \
--cc=lk-netdev@lk-netdev.nosense.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 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).